From owner-freebsd-current@FreeBSD.ORG Tue Nov 30 20:02:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 460AE16A4CE for ; Tue, 30 Nov 2004 20:02:56 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E409243D5C for ; Tue, 30 Nov 2004 20:02:55 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 4A9977A403; Tue, 30 Nov 2004 12:02:55 -0800 (PST) Message-ID: <41ACD1EF.7020704@elischer.org> Date: Tue, 30 Nov 2004 12:02:55 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Dan Nelson References: <20041128233704.GB62951@NitroPhys.welchsmnet.net> <20041129154805.GD5518@dan.emsphone.com> <41AB8174.4090205@elischer.org> <20041129205408.GH5518@dan.emsphone.com> <41AB9151.8070601@elischer.org> <20041130053040.GL5518@dan.emsphone.com> In-Reply-To: <20041130053040.GL5518@dan.emsphone.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: Sean Welch Subject: Re: top under 5.3-RELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2004 20:02:56 -0000 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).