kernel thread as real threads..
julian at elischer.org
Fri Jan 20 11:07:46 PST 2006
Scott Long wrote:
> 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
>> 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. The
> 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.
maybe ps can put '--.--' or 'N/A' for threads with M:N flags on them.
> 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.
I plan to tackle this as part of what I'm doing with kernel threads
I've done all I can do this week but will probably to the stats part
More information about the freebsd-current