Date: Wed, 28 May 2014 10:54:04 -0400 From: John Baldwin <jhb@freebsd.org> To: "Jamie Landeg-Jones" <jamie@dyslexicfish.net> Cc: freebsd-current@freebsd.org, emaste@freebsd.org Subject: Re: Change top's notion of idle processes / threads Message-ID: <201405281054.04691.jhb@freebsd.org> In-Reply-To: <201405281220.s4SCKZcn023546@catnip.dyslexicfish.net> References: <201405231605.26312.jhb@freebsd.org> <201405271637.23332.jhb@freebsd.org> <201405281220.s4SCKZcn023546@catnip.dyslexicfish.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201405281054.04691.jhb>