david_chisnall on Nostr: How many threads does the Linux kernel spawn typically? Last time I attached a ...
How many threads does the Linux kernel spawn typically? Last time I attached a debugger straight after boot it was 900 (I think ZFS was the largest single consumer). The ones for NFS have larger stacks because NFS has some deep calls.
With that many, adding 4 KiB adds almost 4 MiB of wired memory. On a typical desktop, that’s noise and no one cares. For embedded systems (consumer routers and so on) it’s much more of a problem and that’s where the pushback came from last time someone suggested bumping the default.
For the threads associated with userpace threads, it’s different. A userspace thread will have at least a page of userspace stack, a kernel thread structure, and typically a page table page for the stack and its guard page (unless they’re very densely packed), so the memory overhead of a new thread is quite small. If you have a modern x86 machine with AVX-512, you have around 3 KiB just for the CPU state on context switch (kernel threads don’t have FPU state unless they opt in, which most don’t).
Java VMs implement N:M threading, so don’t typically create a lot of kernel threads for a lot of Java threads. The same is true of Go.
The NT kernel was designed at a time when a workstation might have only 4 KiB and so wires just enough disk driver to be able to pull pages back in. All of the metadata required find a page is stored in the invalid PTE. This means that page-table pages can also be paged out, with each step on the page-table walk faulting and bringing back more of the page table until the real page is loaded. Linux and FreeBSD both store extra metadata for paged memory, which is why it’s fairly easy to support things like CHERI and MTE, whereas on Windows it requires significant reachitecture of the virtual memory subsystem. The NT VM subsystem is slightly larger, in lines of code, than a minimal build of the Linux kernel. I completely understand why the NT choices made sense in the early ‘90s but I would not encourage anyone to copy them. Needing a few MiBs more wired memory in exchange for a drastically simpler and more flexible virtual memory model is absolutely the right trade this century.
With that many, adding 4 KiB adds almost 4 MiB of wired memory. On a typical desktop, that’s noise and no one cares. For embedded systems (consumer routers and so on) it’s much more of a problem and that’s where the pushback came from last time someone suggested bumping the default.
For the threads associated with userpace threads, it’s different. A userspace thread will have at least a page of userspace stack, a kernel thread structure, and typically a page table page for the stack and its guard page (unless they’re very densely packed), so the memory overhead of a new thread is quite small. If you have a modern x86 machine with AVX-512, you have around 3 KiB just for the CPU state on context switch (kernel threads don’t have FPU state unless they opt in, which most don’t).
Java VMs implement N:M threading, so don’t typically create a lot of kernel threads for a lot of Java threads. The same is true of Go.
The NT kernel was designed at a time when a workstation might have only 4 KiB and so wires just enough disk driver to be able to pull pages back in. All of the metadata required find a page is stored in the invalid PTE. This means that page-table pages can also be paged out, with each step on the page-table walk faulting and bringing back more of the page table until the real page is loaded. Linux and FreeBSD both store extra metadata for paged memory, which is why it’s fairly easy to support things like CHERI and MTE, whereas on Windows it requires significant reachitecture of the virtual memory subsystem. The NT VM subsystem is slightly larger, in lines of code, than a minimal build of the Linux kernel. I completely understand why the NT choices made sense in the early ‘90s but I would not encourage anyone to copy them. Needing a few MiBs more wired memory in exchange for a drastically simpler and more flexible virtual memory model is absolutely the right trade this century.