Peter Zijlstra <[email protected]> writes: > 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 > machine.
Good point. My worry is that since it's 'snapshot' mode, the buffer(s) will be around potentially for a long time. Otherwise, I'd also prefer to drop the capability wall. Thanks, -- Alex
