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

Yes.
For example, please look at Fig.10, Fig.11 and Fig.12 of the following
technical report [4] (which is already refered in this discussion).

In this result, even if it is cpu intensive benchmark (i.e. there is
no i/o), performace order is:
  better
   ^		- masuda-lab's thread based on asynchronous i/f
   |		- scheduler activations
   |		- traditional userland/kernel mixed thread
   v		- kernel only thread
  worse

You can see that masuda-lab's thread and scheduler activations are
far better than traditional U/K thread and K-only thread.

[4] http://www.is.s.u-tokyo.ac.jp/tech-reports/TR94-02-letter.ps.gz
Shigekazu Inohara and Takashi Masuda.
"A framework for minimizing thread management overhead based on
asynchronous cooperation between user and kernel schedulers."
Technical Report 94-02, Department of Information Science,
Faculty of Science, University of Tokyo, Jan 1994. 
--
soda