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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 13 Feb 2019 17:47:56 +0000
From:   Mel Gorman <mgorman@...hsingularity.net>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
        jolsa@...hat.com
Subject: Re: [PATCH v0 1/2] perf: Add an option to ask for high order
 allocations for AUX buffers

On Wed, Feb 13, 2019 at 02:07:55PM +0100, Peter Zijlstra wrote:
> 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?
> 

It's "protected" in that we try to avoid long-lived unmovable allocations
causing problems but it's internal to the page allocator. The exception
is ZONE_MOVABLE and CMA which has some protection or static pools like
hugetlbfs with tunables and APIs that can strict access if desired.

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

It does. At worse, other unmovable allocations may be allocated elsewhere
in the meantime but that's normal activity. It can be replicated in any
number of innocent ways by a normal user. It's even the basis of a test
case that forces fragmentation, measures THP allocation success rate and
stresses compaction.

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

Shouldn't even be necessary. With the possible exception of hugetlbfs,
the userspace is not forced to take special action to keep the page
allocator happy.

If there is a tangiable performance benefit from using contiguous regions
then I would suggest optimistically allocating them with appropriate
GFP flags to avoid large latencies at startup time and fall back if
necessary. Don't stick it behind capabilities or restrict it to privileged
users. Only hugetlbfs provides restricted access and exposes an
interface to userspace for applications and even that can be
unprivileged.

-- 
Mel Gorman
SUSE Labs