Re: top under 5.3-RELEASE

Dan Nelson wrote:

>In the last episode (Nov 28), Sean Welch said:
>  
>
>>Through 5.2.1-RELEASE I've been accustomed to seeing the top few
>>processes using a % of cpu that correspondes to the % free cpu value
>>in the header part of the output.  Ie, if the machine is 20% idle I
>>expect to see the process %s to add up to roughly 80%.  This seems no
>>longer to be the case under 5.3-RELEASE and I'm rather confused by a
>>0% idle statement with the process %s adding up to only about 15% or
>>so.
>>
>>The amount jumps around a bit and seems to bear the relationship I
>>expect when there is light load, but it looks completely wrong to me
>>when there is heavy load (as in compiling a port).
>>
>>Can anyone explain this seeming inconsistency to me?
>>    
>>
>
>For things like port builds, you end up with a lot of very short-lived
>processes (sh, sed, cc, etc).  Those either don't show up in top at all
>becuase they have started and exited between the sampling intervals, or
>else have not accumulated enough CPU time to register any %CPU (which
>is a weighted average over time).
>
>The values should total up better when you have processes that hang
>around a bit more.  There was a regression in 5.3's libpthreads that
>can make it report 0 CPU, so if you have some CPU-hungry threaded
>programs, they may not show up in top at all even though they're using
>100% cpu.  libthr and libc_r report CPU correctly.
>
As background, libpthread assigns user threads to arbitrary kernel 
threads "as needed".
The trouble is that if a user thread comes into the kernel, uses a 
kernel thread, and then exits the kernel
and another user thread does the same, where can we store the info about 
the first thread?
We have no place to store this info in libpthreads.. at least not in a 
form useful to 'top' and 'ps'.