Re: [PATCH 2/2] perf: arm_spe: Prefer large AUX mappings

[Will Deacon]

On Mon, Oct 05, 2026 at 06:41:44PM +0100, Leo Yan wrote:
> On Thu, Oct 01, 2026 at 08:16:09AM +0100, Will Deacon wrote:
> > On Wed, Sep 30, 2026 at 05:43:11PM +0100, Leo Yan wrote:
> 
> > > How about adding a field to struct pmu to specify a preferred maximum
> > > page order for the AUX buffer? The perf core could try that order first
> > > and fall back to smaller orders if the allocation fails.
> > 
> > I'm not sure that's thr right place for it, really. The driver has no
> > clue about whether it makes sense to use large contiguous mappings or
> > not, so I'd have thought that decision should be driven from userspace
> > (e.g. like MADV_HUGEPAGE) because it really depends on the user's
> > preference and isn't a fixed property of the hardware.
> 
> Here MADV_HUGEPAGE cannot directly apply on this case: perf allocates
> the AUX pages during mmap, while TRBE accesses them through a separate
> kernel vmap() mapping.
> 
> MADV_HUGEPAGE is applied after mmap, but a preference (or flag) would
> need to be specified before the AUX mmap.

I was using the madvise option as an example of a user-controllable hint,
I'm not suggesting you use it directly as-is.

> > > Given the single L1 TRBE TLB entry, the TRBE driver could prefer
> > > PMD_ORDER (2 MiB with 4 KiB pages) to reduce TLB pressure. This reflects
> > > the hardware characteristic.
> > > 
> > > This could be a trade-off instead of using PERF_PMU_CAP_AUX_PREFER_LARGE,
> > > avoiding large contiguous allocations that could reintroduce the Android
> > > OOM issue. I did a quick test with this approach and the results look
> > > positive.
> > 
> > I really don't want the driver to second-guess userspace based on whatever
> > information it happens to have hard-coded about the specific CPU it's
> > running on.
> 
> The kernel already takes the PERF_PMU_CAP_AUX_PREFER_LARGE flag from a
> PMU; a preferred maximum order would let the driver give it a bounded
> value.

But the driver doesn't have this information.

> I do not intend to hard-code or guess a preference for a particular CPU
> variant. We can map TRBE or SPE buffer at PMD granularity. On a 4
> KiB-page system, PMD_ORDER is order 9, or 2 MiB. Requesting a larger
> contiguous chunk cannot increase the mapping granule, so I would cap the
> preference there. It remains a preference: perf can fall back to smaller
> orders when allocation fails.

My understanding of 18049c8cff9c is that it's not about allocation
failures, so this doesn't work.

> Exposing the preference to userspace also seems problematic. Users
> generally lack the hardware details needed to choose an appropriate
> value. Even if tools provide a default, the same policy would need to
> be duplicated across perf, simpleperf, and proprietary tools. I don't
> think userspace tools are the right place for this policy.

Well I don't think it belongs in the kernel either. I suppose you could
make it a driver module option but it's ugly as hell. We really need
Yabin's input here, I think.

Will