top under 5.3-RELEASE
julian at elischer.org
Mon Nov 29 13:14:58 PST 2004
Dan Nelson wrote:
>In the last episode (Nov 29), Julian Elischer said:
>>Dan Nelson wrote:
>>>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'.
>Can you just add the stats to the primary kse (the one with id==pid)?
there is no "primary KSE"
There is a ksegrp associated with every group of threads that could
aggregate this information for all
threads under its umbrella, but ps and top don't know about it.
>That's always around as long as the process exists afaik.
once you have switched to threading mode, all threads are the same and the
original thread is just as likely as any other thread, to be declared
and discarded when teh process requires less kernel threads.
> Any thread
>would do, since you can't guarantee that a thread will use the same kse
>twice anyway. What's annoying is seeing a CPU-bound threaded app
>(mysql or java, for example) showing 0 %CPU in top/ps but the TIME
>column incrementing 1 per second...
but when 'ps' gets the information, it gets each thread.. where does the
info get stored?
the threads may have just flashed into existence a fraction of a second
ago, and prior to that
thay may have belonged to a compeltely different process. It's not a
However there may be some relatively "ok" answers if we can define well
we want to see. For example all taking the total cputime for the KSEGRP
it by the number of non-sleeping threads might be a possibility. (or
some variant of that).
More information about the freebsd-current