eekee wrote:
I remember when Linux had very few processes. There were no kprocs & no udev, but there was also no acpi, wpa, thermal monitoring, automounting... It was refreshing.
It was also very capable, having already powered the rise of the Internet. I'm sure it was less complicated than several active projects on our list right now (but I don't really want to check).
I'm not sure how significant the number of kernel threads is. A number of them are probably not worth representing in ways visible to userspace unless they can be manipulated as tasks, but apart from a relatively purist concern about namespace pollution, are harmless. The real concerns are per-thing overheads and asymptotic complexities for things such as threads, processes, file handles, memory mappings, etc. Easy exercise: a forking server (here the use of
fork() isn't really significant, but rather the fact a new process is spawned for each connection) with a large shared memory segment. Things like to use SHM_HUGETLB on Linux to trim down the pagetable space overhead by a constant factor, but it's still quadratic: linear in the number of processes times linear in the size of the shared memory segment, K*p*v. This is a very significant real-world example. Shared pagetables (mind you, all the way up the radix tree hierarchy) would render the overhead of a forking server merely linear in the virtualspace for mapping shared memory plus linear in the number of processes. (I suspect out-of-tree patches for Linux to do so might still be around.) There are also concerns about the pinned memory usage, say, per-thread and perhaps per-process. Discarding reconstructible pagetables and potentially swapping pagetables that aren't reconstructible from e.g. file offset calculations can render potentially very large kernel data structures un-pinned. For threads, M:N threading in combination with asynchronous system calls can cut down the space overhead for running threads' kernel stacks to one per CPU in tandem with smaller queued callbacks per blocked user thread for potentially very significant constant factor reductions in pinned memory per thread.
Compared to such concerns, user-visible kernel-spawned kernel threads that are only O(nr_cpus) in number are IMNSHO negligible. Not to say I'm not one of the purists who disapproves of the pid namespace pollution.