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 14:09 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 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.