Dan Nelson wrote: >In the last episode (Nov 29), Julian Elischer said: > > >>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). >> >> > >Is the real problem that %CPU and WCPU are no longer used by the >schedulers in any meaningful way? I thought at one point they were >used to dampen the priority of cpu-intensive proceses. Maybe they >should be removed and replaced with some other counters that can record >cpu usage better. %CPU can certainly be extracted by subtracting the >"struct rusage" values every sampling interval; unixtop does that for >quite a few OSes where %CPU isn't available or is useless. WCPU is >nice to get a longer-term picture of what processes are consistently >using CPU though. I suppose top could maintain its own running average >by averaging its calculated %CPU over an interval, but ps couldn't. > Actually the problem is deper than that. Prior behaviour SHOULD be used by the schedulers but there is no way for us to meaningfully track it for a threaded program. (for the reasons mentionned before).Received on Tue Nov 30 2004 - 19:02:56 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:23 UTC