> 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.


Martin