Re: kernel thread as real threads..

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

>
> Scott