All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, jolsa@redhat.com,
	mgorman@techsingularity.net
Subject: Re: [PATCH v0 1/2] perf: Add an option to ask for high order allocations for AUX buffers
Date: Wed, 13 Feb 2019 14:07:55 +0100	[thread overview]
Message-ID: <20190213130755.GQ32494@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20190213114716.63972-2-alexander.shishkin@linux.intel.com>

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.

  reply	other threads:[~2019-02-13 13:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-13 11:47 [PATCH v0 0/2] perf: Allow forcing high-order allocation for AUX buffers Alexander Shishkin
2019-02-13 11:47 ` [PATCH v0 1/2] perf: Add an option to ask for high order allocations " Alexander Shishkin
2019-02-13 13:07   ` Peter Zijlstra [this message]
2019-02-13 13:49     ` Alexander Shishkin
2019-02-13 17:47     ` Mel Gorman
2019-02-13 17:54       ` Peter Zijlstra
2019-02-13 19:17         ` Mel Gorman
2019-02-13 11:47 ` [PATCH v0 2/2] perf record: Add --aux-highorder Alexander Shishkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190213130755.GQ32494@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@redhat.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.