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. > nope.. 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 "surplus" 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... > understood.. 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 simple problem. However there may be some relatively "ok" answers if we can define well enough what we want to see. For example all taking the total cputime for the KSEGRP and dividing it by the number of non-sleeping threads might be a possibility. (or some variant of that). > > >Received on Mon Nov 29 2004 - 20:14:58 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:23 UTC