Re: kernel thread as real threads..

Scott Long wrote:

> Julian Elischer wrote:
>
>> Kris Kennaway wrote:
>>
>>>
>>> Correct me if I'm wrong, but the stats aren't accounted to the parent
>>> process either.  I'm pretty sure I've seen situations where a thread
>>> was using a lot of CPU, but if you believe top(1) then every process
>>> in the system is idle (except for the fact that the system is 0%
>>> idle).  In this situation there's no way to tell which threaded
>>> process is using resources.
>>>  
>>>
>>
>> you may be right.. I plan to examine stats over the next week as part 
>> of the kernel threads work.
>> I may be able to improve the situation.
>>
>
> Um, would this be considered a security flaw, since process time limits
> likely aren't being enforced?

I won't know before looking but some accumulation of sats to teh process 
is happenning already
(but not being shown) so it may still be being enforced.. it's not that 
simple.

>
>> my aim is that for threads that are doing M:N work the stats will 
>> accumulate on the thread
>> for a short while and then be collected to the KSEG when ther eis 
>> reason to think that
>> the kernel thread has changed purpose or exits (both of which happen 
>> a lot in KSE).
>>
>> for 1:1 threads, they will continue to accumulate on the thread, 
>> since no "KSE events" will
>> occur.
>>
>> The KSEGRPs stats will be collected to the process when asked for.
>> I will probably also change the way that 'ps' shows these (and 
>> threads). I'm not sure what to do about top yet. we really need to be 
>> able to show a
>> process name AND a thread name when the threads are shown and have 
>> names.
>>
>>> Kris
>>>
>
> Does pthreads allow the programmer to name threads in a user and/or
> kernel visible way?  Is this something that is really all that
> important?


There is a way,
but it's more important for kernel threads.. it's nice to see which  is 
which.
Even in user threads (1:1) if one thread is running away, it's nice to 
see which one it is.

We should have an interface on M:N thread sto allow a process to get 
thread stats.. probably implemented as
a management thread or something. (maybe the signal thread could do it).


>
> Scott