From owner-freebsd-current@FreeBSD.ORG Tue May 27 20:37:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41D3EA92; Tue, 27 May 2014 20:37:33 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 18F4E2331; Tue, 27 May 2014 20:37:33 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0CBF7B924; Tue, 27 May 2014 16:37:32 -0400 (EDT) From: John Baldwin To: Ed Maste Subject: Re: Change top's notion of idle processes / threads Date: Tue, 27 May 2014 16:37:23 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <201405231605.26312.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201405271637.23332.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 27 May 2014 16:37:32 -0400 (EDT) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 27 May 2014 20:37:33 -0000 On Tuesday, May 27, 2014 10:43:56 am Ed Maste wrote: > On 26 May 2014 11:51, Ed Maste wrote: > > > > The change in the patch is good, the new behaviour is much more > > usable. Note that we don't currently define "idle" in top(8); for > > this change maybe we should just state that non-idle processes may > > report 0% CPU due to rounding. > > That said, I've discovered an issue with the change after using it a > bit more, when using -I on the command line. (Previously I only tried > it by pressing I in interactive mode.) With the change top -I lists > all processes at first (which is a little annoying), but it renders -I > ineffective when used with -b (batch mode). > > What do you think about this additional change, so that we use the > previous 0% idleness test for the first iteration of the list: > > if (oldp == NULL) > - return (pp->ki_runtime != 0); > + return (pp->ki_pctcpu != 0); Not a bad idea. I have another change that also reworks how ki_pctcpu is calculated. Namely, if this is a subsequent update and we have the kinfo_proc from the previous update (or if the process/thread in question is a newborn since the previous update) this patch uses delta(ki_runtime) / delta(CLOCK_UPTIME) to calculate a true %CPU across the interval. As opposed to the scheduler-calculated %CPU which has a long delay function, this causes the %CPU column in top to reflect changes in behavior much more quickly and to also give a more accurate view of mostly-idle processes and threads. However, in actual use it seems to have some jitter as I can't atomically grab a CLOCK_UPTIME value with the kern.proc sysctl info. As a result, I see occasional rounding errors where a 'while (1)' loop can oscillate between 98 and 102% CPU usage for example. Still, if you start a while (1) loop, it jumps to the top of the list much quicker (and falls off as soon as you pause it). For the initial fetch (and for batch mode) it uses the scheduler- calculated value still. I also adopted phk@'s suggestion of counting changes in ru_nvcsw/ru_nivcsw as evidence of running. http://people.freebsd.org/~jhb/patches/top_pctcpu.patch -- John Baldwin