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

From: John Baldwin <jhb_at_freebsd.org>
Date: Wed, 28 May 2014 10:54:04 -0400
On Wednesday, May 28, 2014 8:20:35 am Jamie Landeg-Jones wrote:
> John, the changes are good.
> 
> The "'trickling' but still not idle" processes now show up as they should.
> 
> However, it has exposed one quirk in the display:
> 
> Sorting is done by WCPU followed by total processor time.
> 
> Processes which aren't idle (but are using so little cpu it shows as 0.00%)
> show below processes which are truely idle, but have totaled more processor
> time overall.
> 
> This is more noticable with your new patch, as toggling between idle-only
> and full now shows processes appearing higher in the list than some which
> only appear in the non-idle view!
> 
> Ideally, processes where cpu "is virtually 0.00% but really a smidgen higher"
> should be display higher.
> 
> I realise the pctcpu granularity is at fault here.
> 
> Basically, what I'm saying is that truely idle processes should appear below
> other processes reporting 0.00% cpu.
> 
> In other words, what I'm asking is: shouldn't the cpu sort priority not
> simply be keyed on 'ki_pctcpu', but on a primary key based on
> "if cur->ki_runtime == old->ki_runtime ?" followed by secondary key ki_pctcpu. 
> 
> Or even easier, shouldn't simply sorting on (cur->ki_runtime - old->ki_runtime)
> suffice?
> 
> Is this a valid point, and if it is, is it practical, and/or easy enough to
> achieve? I'll even have a stab at it myself tomorrow, after hopefully getting
> some sleep (32 hours without sleep - sorry for incoherency - insomnia is a PITA)

Yes, I actually started by sorting on the raw delta and ended up going back and fixing
pctcpu instead.  However, there is a problem in this case which is that you
still want to fall back to ki_pctcpu if you don't have a valid previous delta
to compare against.  It's a lot simpler to just fixup ki_pctcpu and not have to go
change the sorting code explicitly. :(  I actually started out having a function that
returned a double for the pctcpu, but that would mean recalculating the raw pctcpu
many, many times during the sort.  Just updating ki_pctcpu once per each process/thread
per fetch scales a bit better.  I could perhaps use an array to cache raw percentages
as doubles.

Ok, try people.freebsd.org/~jhb/patches/top_pctcpu2.patch

-- 
John Baldwin
Received on Wed May 28 2014 - 13:59:11 UTC

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