Re: [PATCH] xfs: add per-mount read/write I/O completion counters

[Eric Peterson]

On Mon, Aug 31, 2026 at 09:38 UTC, Dave Chinner wrote:
> Hence I'm asking how this new metric is supposed to be used and
> correlated to observed/measured application behaviour. i.e. what
> insight does it give you into application performance that can only
> be derived from this point in time snapshot?

My apologies - it wasn't my intention to come across as patronizing.
I was unsure what background was or wasn't common ground, so I erred on
the side of more detail.

You're right about the sampling limitation: a slowly-sampled
point-in-time queue depth value cannot characterize bursty,
sub-interval concurrency. If the goal is to resolve what happens inside
a 10ms burst, this is the wrong tool - per-op tooling (tracepoints,
histograms) is the right one, and this is not meant to replace it.

The important part is that this is a property of the sampling rate, not
of the counters. Nyquist-Shannon says that to observe a phenomenon at
timescale T you have to sample at >= 2/T; if you sample slower than the
behavior you care about, it will be missed. This is true of any sampled
counter, including the existing submission counter - in your 10Hz pmval
example, xfs.read has exactly the same property. The sampling rate is a
policy choice for the user to match to what they're trying to observe.

Answering your question, it lets userspace characterize filesystem
queue depth over time. The places where this is useful are the ones
where the desired signal persists across multiple sample periods,
leading to a representative measurement:

 - Sustained/steady-state load.
   Database, NFS server, VM image store, etc. Outstanding I/O is stable
   across many sample periods. Most capacity and health monitoring
   lives here.

 - Long-horizon trends.
   Can show if queue depth is creeping up over hours or days as load
   grows or cache becomes insufficient. Leaving per-op tracing running
   for this kind of timescale is the wrong tool for the job; persistent,
   low-cost sampling is the better choice.

 - Sustained-backlog alerting.
   Consistent elevated depth can indicate saturation, a stuck consumer,
   or cache thrash. Filtering out small transients avoids adding noise.

 - Coarse steady-state latency.
   When load is steady, sustained depth over sustained completion rate
   gives an average latency - enough precision to tell 0.5ms from 5ms,
   but not tail latency. Histograms would be the correct tool if higher
   resolution is required.

For higher precision you'd want a time-weighted queue depth, but that
requires two clock reads on every I/O in the hot path, and the cost
grows with I/O load. This trade-off is the core motivation: the counter
is a near-free, always-on aggregate for the common steady-state and
trend cases. It does not replace per-op tooling where higher precision
is required.

-Eric