On Thu, Oct 08, 2026 at 04:13:27PM +0530, Dev Jain wrote:
Commit 18049c8cff9c ("perf/aux: Allocate non-contiguous AUX pages by default") made the AUX allocator use order-0 pages by default unless a PMU explicitly asks for contiguous allocations.
But that commit specifically calls out SPE as benefitting from non-contiguous pages:
"For instance, ARM SPE and TRBE operate with virtual pages, and Coresight ETR allocates a separate buffer. For these PMUs, allocating contiguous AUX pages unnecessarily exacerbates memory fragmentation. This fragmentation can prevent their use on long-running devices."
so why doesn't passing PERF_PMU_CAP_AUX_PREFER_LARGE reintroduce the problems that 18049c8cff9c was trying to solve?
I don't have the full context here (can look in detail later) so drive-by comment:
In general, doing large order allocations should *reduce* fragmentation. If you allocate 16 order-0 pages as opposed to an order-4 compound page, you may end up spreading your allocations across different blocks, thus preventing them from merging later.
A recent example can be found in vmalloc [1].
[1] https://lore.kernel.org/all/aPjrRkjiIt6HmXmT@casper.infradead.org/
Thanks, Dev. Roughly read the shared link, larger allocations can keep pages with the same lifetime together, so order-0 allocation is not necessarily better for fragmentation.
As mentioned in my other reply, the AUX buffer allocator already used __GFP_NORETRY before the commit 18049c8cff9c, so those allocations do not directly invoke the kernel OOM killer.
This calls for revisiting that rationale in 18049c8cff9c. The original issue does not appear to have been investigated sufficiently, and we still haven't received further details since this series.
I propose reverting 18049c8cff9c to restore the previous allocation policy. If no objections, I will send a revert for review.
Thanks, Leo