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

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.

It would be easier for others to understand the proposal if the
changelog were to quote some sample /proc/vmstat output.

> Signed-off-by: Daniil Tatianin <[email protected]>

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.