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

John Baldwin <jhb_at_freebsd.org> wrote:
> 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.

Sorry for the delay in getting back to you.

Thanks for the explanation - it makes sense. (I mean that I understand what you are
saying - not that I'm somehow misguidingly attempting to give my approval!)

I can see how improving the granularity of pctcpu would be a much cleaner solution -
I just didn't know which solution was easier (and after finally looking at the source,
I still didn't know :-) )

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

Brilliant. I wasn't able to get contradictory results this time - however much I
tried!

I have a few server processes that are constantly active (receiving many requests
per second) but use a well written piece of code that handles them efficiently.

With the stock 10-stable, and with the previous patch, they always registered as
0.00% cpu (and consequently were not shown at all in idle-only mode on 10-stable)

(I'm not doubting the general stats - I reconfigured one of them earier today, and
in 7 hours it's clocked up 2.2 seconds)

With the latest patch, they now report as 0:01% which not only corrects the sort
order, but makes more sense than 0.00% for a non-idle process, even if the value
before rounded is closer to 0.00 than 0.01

Other processes which are generally in tick-over, but also idle much of the time
now pop in and out of view as expected, and sorted as expected.

....not sure what you've done.... I'm guessing without looking at the patch code
(lazy persons approach) that you have either improved the accuracy of pctcpu,
or you now round any non-idle cpu usage below 0.00 up to 0.01

Whatever.... It works.

The old top was mainly handy for watching heavy usage processes (don't get me
wrong, it's invaluable for that).

The new top is now also producing results similar to what I'd previously had
to manually extrapolate from a series of repeated targetted 'ps' commands.

I'll let you know if I notice anything weird, or if I manage to break anything :-)
but I'm confident that this won't happen.

A BIG thumbs up for this... Push into current, then MFC now! :-)

Cheers,
Jamie