Re: [PATCH] mm/vmstat: add per-order allocation slow path statistics

On Thu 20-08-26 15:49:13, Andrew Morton wrote:
> On Thu, 20 Aug 2026 16:36:58 +0300 Daniil Tatianin <[email protected]> wrote:
> 
> > Production incidents caused by bursts of high-order allocations all
> > entering direct compaction are currently hard to attribute from
> > /proc/vmstat: pgalloc_* has no order breakdown, and compact_stall does
> > not say which order stalled. Tracepoints can recover this on a single
> > machine, but they are impractical as an always-on fleet-wide monitoring
> > source, which is what is needed to correlate latency regressions with
> > allocation behavior after the fact.
> > 
> > Add per-order event counters to /proc/vmstat, covering only the
> > allocation slow path, so the page allocator fast path is not touched
> > at all:
> > 
> >  - pgalloc_slowpath_orderN: entries into __alloc_pages_slowpath(),
> >    counted once per allocation, before the restart loop
> >  - pgalloc_fail_orderN: allocations that returned NULL to the caller
> >    (including a successful allocation freed by memcg charge failure)
> >  - compact_stall_orderN / compact_success_orderN: per-order split of
> >    the existing direct compaction counters, order 0 is omitted since
> >    direct compaction is never entered for it
> > 
> > All new counters are purely additive: the existing keys are untouched
> > and compact_stall == sum of compact_stall_orderN.
> > 
> > alloc_pages_nolock() is deliberately not counted: it is opportunistic,
> > never enters the slow path, and its NULL returns are expected rather
> > than failures.
> > 
> > Counter names are generated for any MAX_PAGE_ORDER the arch Kconfig
> > ranges allow (10..13), a static_assert catches larger values.
> 
> AI review got upset about this:
> 	https://sashiko.dev/#/patchset/[email protected]
> 
> > A per-order split of PGALLOC itself was proposed in 2017 but stalled
> > over fast path overhead concerns, restricting the counters to the slow
> > path avoids that overhead entirely while still capturing the
> > allocations that cause latency.
> 
> Seems useful, thanks.

I would rather not put that into ever growing vmstat and bloat it even
more. Most users simply do not care about that level of details. What do
we expect next, per migrate target/order stats because somebody might be
interested to debug fragmentation better?

Would it be sufficient to have a dedicated debugfs interface? The
argument about tracepoints scalability is also rather weak. There are
examples of successfull bpf, tracing deployments at large scales so this
certainly is not a new problem to tackle.

-- 
Michal Hocko
SUSE Labs