Date: Mon, 29 Nov 2004 23:30:41 -0600 From: Dan Nelson <dnelson@allantgroup.com> To: Julian Elischer <julian@elischer.org> Cc: Sean Welch <Sean_Welch@alum.wofford.org> Subject: Re: top under 5.3-RELEASE Message-ID: <20041130053040.GL5518@dan.emsphone.com> In-Reply-To: <41AB9151.8070601@elischer.org> References: <20041128233704.GB62951@NitroPhys.welchsmnet.net> <20041129154805.GD5518@dan.emsphone.com> <41AB8174.4090205@elischer.org> <20041129205408.GH5518@dan.emsphone.com> <41AB9151.8070601@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Dan Nelson dnelson@allantgroup.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041130053040.GL5518>