systat(1): vmstat: compute rates with CLOCK_UPTIME
systat(1)'s vmstat view displays rates for things like interrupts.
Strangely, it uses CPU time to compute these rates, not real time.
This is potentially misleading, particularly on an MP system. If I
have 4 cores running on a HZ=100 kernel I expect ~400 clock interrupts
per second. But systat(1) tells me I have 100 because we have 4
seconds worth of CPU time for every second of real time that elapses.
I don't like it. I want to see how many interrupts there really were.
This patch changes the vmstat view to use CLOCK_UPTIME to measure
elapsed time and uses that when computing rates. The "Big Bar" is
still drawn using CPU time, but for everything else I think you would
want a rate based on the elapsed real time. Using CPU time isn't
We want CLOCK_UPTIME, not CLOCK_MONOTONIC, because we aren't
interested in what the machine was doing when it was suspended.
I have not changed dinfo() to keep the patch simple, but we should be
using CLOCK_UPTIME there, too.
Re: systat(1): vmstat: compute rates with CLOCK_UPTIME
On Wed, Sep 16, 2020 at 01:20:16AM -0600, Theo de Raadt wrote:
> Two days ago during my work on ongoing work for non-acpi suspend,
> kettenis and I observed the same thing.
> your diff works very well for me.
Okay, so I'm not the only one.
Let's do the full patch:
- All rates in the vmstat view are now computed using elapsed
real time, not elapsed CPU time.
- Measure elapsed real time with CLOCK_UPTIME and not
CLOCK_MONOTONIC because we don't care about time spent
- Pass the elapsed time to dinfo() to use when computing
I/O rates instead of assuming how much time has elapsed.
- Keep drawing the big bar using CPU time.
Would appreciate more tests from people who depend upon systat(1)
regularly. Does the vmstat view on your machine look reasonable with