Re: [PATCH v0 1/2] perf: Add an option to ask for high order allocations for AUX buffers

From: Peter Zijlstra
Date: Wed Feb 13 2019 - 08:08:06 EST

On Wed, Feb 13, 2019 at 01:47:15PM +0200, Alexander Shishkin wrote:
> Currently, the AUX buffer allocator will use high-order allocations
> for PMUs that don't support hardware scatter-gather chaining to ensure
> large contiguous blocks of pages, and always use an array of single
> pages otherwise.
> There is, however, a tangible performance benefit in using larger chunks
> of contiguous memory even in the latter case, that comes from not having
> to fetch the next page's address at every page boundary. In particular,
> a task running under Intel PT on an Atom CPU shows 1.5%-2% less runtime
> penalty with a single multi-page output region in snapshot mode (no PMI)
> than with multiple single-page output regions, from ~6% down to ~4%. For
> the snapshot mode it does make a difference as it is intended to run over
> long periods of time.
> Following the above justification, add an attribute bit to ask for a
> high-order AUX allocation. To prevent an unprivileged user from using up
> the higher orders of the page allocator, require CAP_SYS_ADMIN for this
> option.

Why do we need a knob for that? Last time I checked unpriv users could
fragment the page allocator just fine. What is there to protect?

Also, since we return all pages upon buffer free, the page allocator
should in fact re-construct the high order stuff.

So a buffer alloc + free, using high order pages, should be an effective
nop on high order availability.

Unlike spraying dentries or whatever works these days around the