Messages in this thread | | | Date | Wed, 7 May 2003 10:38:25 -0700 | From | William Lee Irwin III <> | Subject | Re: top stack (l)users for 2.5.69 |
| |
On Wed, May 07, 2003 at 06:49:01PM +0200, J?rn Engel wrote: > It also matters if people writing applications for embedded systems > have a fetish for many threads. 1000 threads, each eating 8k memory > for pure existance (no actual work done yet), do put some memory > pressure on small machines. Yes, it would be possible to educate those > people, but changing kernel code is more fun and less work.
If they're embedded and UP they can probably get by on a userspace threading library that only creates one kernel thread.
It's highly unlikely anyone will get anywhere "fixing" this in the kernel. The closest approximations to mitigating the pinned memory overhead with UNIX-style kernel semantics are swappable stacks a la the u area and M:N threading, neither of which are popular notions. If you're trying the other approach I mentioned in this thread, good luck ever getting it done and good luck ever surviving even a single merge.
$ grep -nr schedule . | wc -l 3773
Basically monsterpatch Hell for a resource scalability problem no one's taking very seriously at the moment. We're already into the territory of trivially userspace-triggerable NMI oopsing on 32x with merely linear algorithms on 10000 threads, so the VM side isn't even worth talking about until answers for the issues triggerable with the thread counts the VM can currently handle appear, and even then only if there is some real demand from apps and/or systems for it.
Just consider forkbombing infeasible; most (if not all) forkbombing apps do so out of stupidity or outright bugs. 32-bit machines have something to do mostly because pagetables are enormous and many process address spaces are needed to establish per-sub-pool mappings and are largely an entirely separate issue from general thread scalability (it adds up to a lot of processes but usually well under 50000 and mostly vastly less).
-- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |