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

[Daniil Tatianin]

Thanks for the quick review!

On 8/21/26 1:49 AM, Andrew Morton wrote:
> On Thu, 20 Aug 2026 16:36:58 +0300 Daniil Tatianin <d-tatianin@xxxxxxxxxxxxxx> 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/20260820133659.712111-1-d-tatianin@xxxxxxxxxxxxxx

Indeed, it appears PowerPC even does 7 in some cases.
Will fix in v2 in a second.

> > 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.
>
> It would be easier for others to understand the proposal if the
> changelog were to quote some sample /proc/vmstat output.

Agreed, will attach in v2.

> > Signed-off-by: Daniil Tatianin <d-tatianin@xxxxxxxxxxxxxx>
> Merging patches from Russian-affiliated individuals is problematic.  As
> I understand it (not well) it's OK if the contributor's organization
> isn't on the US's OFAC list, and it appears that Yandex is not on that
> list.

Can't comment because I don't know either