Re: Change top's notion of idle processes / threads

From: John Baldwin <jhb_at_freebsd.org>
Date: Wed, 28 May 2014 09:41:13 -0400
On Sunday, May 25, 2014 3:11:05 am Kubilay Kocak wrote:
> On 24/05/2014 7:22 AM, Allan Jude wrote:
> > On 2014-05-23 16:05, John Baldwin wrote:
> >> Right now, when top is set to not display idle processes or threads, it only 
> >> displays processes or threads that are currently in a runnable state or have a 
> >> non-zero %cpu.  However, our %cpu is quite imprecise.  I have patch to change 
> >> top to instead compare the thread or processes runtime (ki_runtime in 
> >> kinfo_proc) against the runtime of the thread or process the last time data 
> >> was fetched.  In essence, top will consider any thread that has run on a CPU 
> >> since the last update as non-idle.  The end result is that mostly-idle threads 
> >> and processes will now be visible in top's idle display.  Personally, I find 
> >> this more useful (and find the current implementation completely useless).  
> >> The patch is at http://people.freebsd.org/~jhb/patches/top_idle.patch
> >>
> >> Comments?
> >>
> > 
> > I think this makes good sense. I would definitely prefer it. Would it
> > make sense to maybe preserve the old behaviour behind a command line flag?
> > 
> 
> And an update to top(8) reflecting the algo :) I know these little
> esoteric things could always do with more obvious breadcrumbs (like load
> average calcs, etc) for our future selves and others.

As Ed noted, the manpage is already fairly vague here.  Given the responses
so far, everyone finds the new behavior more intuitive than the old one.

> +1 on the behavior change, not sure about retaining the old under a
> flag. Who might benefit from it? How do other OS top implementations
> calculate their idle? If there's other examples out there with the same
> (current) algo, then retaining compat might be worth it, such as for
> newly converted users

This isn't really that big of a behavior change in practice.  It is just
using a more precise measurement for the current 'ki_pctcpu != 0' test
that is already there.

-- 
John Baldwin
Received on Wed May 28 2014 - 11:42:08 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:49 UTC