> From: "Martin Husemann" <martin@rumolt.teuto.de>
>
> > This is the absolute, complete antithesis of scheduler activations, as
> > it gives you an insane amount of overhead.  It would actually be
> > *cheaper* to just have one `kernel thread' per user thread.
>
> This might proove my ignorance, but I don't see the big win in having
> userland libraries fake more threads to the application than the kernel
> supports (with the one big exception beeing the kernel only supporting a
> single thread).
>
> Are there any results on the value of additional-userland-threads available,
> mesured in real world scenarios?
>
> What does making this additional threads real kernel threads cost, besides a
> slightly slower thread creation? This doesn't mean all these threads should
> be considererd runnable at any time, we could create two run queues with the
> number of threads on the primary being limited to a maximum determined by
> the number of CPUs and a tuneable parameter.

Sorry if this is the obvious answer, but the cost is not just time but also
space, and in whether that space is pagable, and in whether that space
comes out of the (typically more limited) kernel address space.  Individual
maps and pools within the kernel may have sublimits as well.

As you know, kernel threads are needed for each SMP cpu and for each
outstanding synch I/O op you want to support, and so sophisticated thread
systems multiplex a potentially large number of pure user threads down to
a smaller number of kernel threads in order to get the various advantages
of both types of system.

Apparently, some database servers like to have thousands and thousands of
threads. It's hard to imagine how this would be a good thing for the kernel
to be aware of.

	ross