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

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 <[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]

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 <[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.

Can't comment because I don't know either