From: Ingo Molnar <mingo@kernel.org>
To: James Clark <james.clark@linaro.org>
Cc: Yabin Cui <yabinc@google.com>,
coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Mike Leach <mike.leach@linaro.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>, Jiri Olsa <jolsa@kernel.org>,
Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Liang Kan <kan.liang@linux.intel.com>
Subject: Re: [PATCH 1/2] perf: Allow non-contiguous AUX buffer pages via PMU capability
Date: Tue, 22 Apr 2025 14:49:54 +0200 [thread overview]
Message-ID: <aAeQcgmL-iqGbG_g@gmail.com> (raw)
In-Reply-To: <48640298-effa-42d4-9137-a18a51637f03@linaro.org>
* James Clark <james.clark@linaro.org> wrote:
>
>
> On 21/04/2025 10:58 pm, Yabin Cui wrote:
> > For PMUs like ARM ETM/ETE, contiguous AUX buffers are unnecessary
> > and increase memory fragmentation.
> >
> > This patch introduces PERF_PMU_CAP_AUX_NON_CONTIGUOUS_PAGES, allowing
> > PMUs to request non-contiguous pages for their AUX buffers.
> >
> > Signed-off-by: Yabin Cui <yabinc@google.com>
> > ---
> > include/linux/perf_event.h | 1 +
> > kernel/events/ring_buffer.c | 6 ++++++
> > 2 files changed, 7 insertions(+)
> >
> > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > index 0069ba6866a4..26ca35d6a9f2 100644
> > --- a/include/linux/perf_event.h
> > +++ b/include/linux/perf_event.h
> > @@ -301,6 +301,7 @@ struct perf_event_pmu_context;
> > #define PERF_PMU_CAP_AUX_OUTPUT 0x0080
> > #define PERF_PMU_CAP_EXTENDED_HW_TYPE 0x0100
> > #define PERF_PMU_CAP_AUX_PAUSE 0x0200
> > +#define PERF_PMU_CAP_AUX_NON_CONTIGUOUS_PAGES 0x0400
> > /**
> > * pmu::scope
> > diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
> > index 5130b119d0ae..87f42f4e8edc 100644
> > --- a/kernel/events/ring_buffer.c
> > +++ b/kernel/events/ring_buffer.c
> > @@ -710,6 +710,12 @@ int rb_alloc_aux(struct perf_buffer *rb, struct perf_event *event,
> > max_order = ilog2(nr_pages);
> > watermark = 0;
> > }
> > + /*
> > + * When the PMU doesn't prefer contiguous AUX buffer pages, favor
> > + * low-order allocations to reduce memory fragmentation.
> > + */
> > + if (event->pmu->capabilities & PERF_PMU_CAP_AUX_NON_CONTIGUOUS_PAGES)
> > + max_order = 0;
> > /*
> > * kcalloc_node() is unable to allocate buffer if the size is larger
>
> Hi Yabin,
>
> I was wondering if this is just the opposite of
> PERF_PMU_CAP_AUX_NO_SG, and that order 0 should be used by default
> for all devices to solve the issue you describe. Because we already
> have PERF_PMU_CAP_AUX_NO_SG for devices that need contiguous pages.
> Then I found commit 5768402fd9c6 ("perf/ring_buffer: Use high order
> allocations for AUX buffers optimistically") that explains that the
> current allocation strategy is an optimization.
>
> Your change seems to decide that for certain devices we want to
> optimize for fragmentation rather than performance. If these are
> rarely used features specifically when looking at performance should
> we not continue to optimize for performance? Or at least make it user
> configurable?
So there seems to be 3 categories:
- 1) Must have physically contiguous AUX buffers, it's a hardware ABI.
(PERF_PMU_CAP_AUX_NO_SG for Intel BTS and PT.)
- 2) Would be nice to have continguous AUX buffers, for a bit more
performance.
- 3) Doesn't really care.
So we do have #1, and it appears Yabin's usecase is #3?
I strongly suspect that #2 and #3 are mostly the same in practice, and
that we don't really need a lot of differentiation and complexity here,
just the AUX_NO_SG flag that must have a max-order allocation - all
other cases should allocate the AUX buffer in a default-nice,
MM-friendly way.
Thanks,
Ingo
next prev parent reply other threads:[~2025-04-22 12:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-21 21:58 [PATCH 0/2] perf,coresight: Reduce fragmentation with non-contiguous AUX pages for cs_etm Yabin Cui
2025-04-21 21:58 ` [PATCH 1/2] perf: Allow non-contiguous AUX buffer pages via PMU capability Yabin Cui
2025-04-22 10:21 ` James Clark
2025-04-22 12:49 ` Ingo Molnar [this message]
2025-04-22 14:10 ` Leo Yan
2025-04-23 19:52 ` Yabin Cui
2025-04-28 8:56 ` James Clark
2025-04-29 17:02 ` Yabin Cui
2025-04-29 21:35 ` Yabin Cui
2025-04-21 21:58 ` [PATCH 2/2] coresight: etm-perf: Add AUX_NON_CONTIGUOUS_PAGES to cs_etm PMU Yabin Cui
2025-04-22 14:21 ` Leo Yan
2025-04-23 20:01 ` Yabin Cui
2025-04-24 11:29 ` Anshuman Khandual
2025-04-24 18:32 ` Yabin Cui
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=aAeQcgmL-iqGbG_g@gmail.com \
--to=mingo@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=coresight@lists.linaro.org \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mike.leach@linaro.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=suzuki.poulose@arm.com \
--cc=yabinc@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).