kernel thread as real threads..

Scott Long scottl at
Fri Jan 20 01:21:00 PST 2006

Gleb Smirnoff wrote:

> On Fri, Jan 20, 2006 at 01:19:55AM -0500, Kris Kennaway wrote:
> K> > the example I showed was the 'ps' from ddb which of course doesn't show 
> K> > any stats anyhow.
> K> 
> K> Yeah, I know that, but they're also not displayed in ps(1) or top(1),
> K> etc.
> And this is a serious issue, that is present in our last releases. If a
> was a newbie installing FreeBSD for first time, this fact will hurt my
> impression about operating system most.

For KSE, threads are just a figment of the imagination of the kernel.  A 
thread that
the kernel sees has no specific correlation to a thread that exists in 
an application.
Trying to associate stats with these threads is absolultely meaningless. 
processing time accumulated for a particular thread that the kernel sees 
could well
be the aggregate of a number of user threads, and those user threads are 
likely migrating
between the kernel threads.  That's the whole point of M:N threading 
=-)  Saying that
thread 1 did X amount of work and thread 2 did Y amount of work simply 
has no meaning,
other than that the parent process did X+Y amount of work.

For 1:1 threading is does make a little more sense.  We'd have to come 
up with a way
to accurately express whether the thread accounting stats are meaningful 
or not depending
on which library is in use.  Adding to the complexity would be that KSE 
can create system
and process scope threads, and that system scope threads behave mostly 
like 1:1 threads.
If someone wants to tackle all of this, that would be great, but my only 
request would be
that it can't sacrifice clarity in one library over another library.


More information about the freebsd-current mailing list