Date: Tue, 27 May 2014 16:37:23 -0400 From: John Baldwin <jhb@freebsd.org> To: Ed Maste <emaste@freebsd.org> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Change top's notion of idle processes / threads Message-ID: <201405271637.23332.jhb@freebsd.org> In-Reply-To: <CAPyFy2B-C-Lm0EtvrHHVcgr_S-Q3oTEkPVVb1TjEuj21jkFg=Q@mail.gmail.com> References: <201405231605.26312.jhb@freebsd.org> <CAPyFy2B1agRySh_ceqcaAM2SR=7LbVvscDQEe524HJeY2ha%2BNg@mail.gmail.com> <CAPyFy2B-C-Lm0EtvrHHVcgr_S-Q3oTEkPVVb1TjEuj21jkFg=Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, May 27, 2014 10:43:56 am Ed Maste wrote: > On 26 May 2014 11:51, Ed Maste <emaste@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201405271637.23332.jhb>