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 BaldwinReceived 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