From: Namhyung Kim <namhyung@kernel.org>
To: Magnus Lindholm <linmag7@gmail.com>, Ian Rogers <irogers@google.com>
Cc: Matt Turner <mattst88@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
James Clark <james.clark@linaro.org>,
linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v4 0/3] perf alpha: Decode ProfileMe samples
Date: Tue, 10 Nov 2026 22:25:51 -0800 [thread overview]
Message-ID: <avQKb-vBxTvMn1yF@z2> (raw)
In-Reply-To: <CA+=Fv5RBKVAdGgq=BGPmLXpczcB3qvQcSw8aat7nB2ePXcG4yg@mail.gmail.com>
Hello,
On Tue, Nov 10, 2026 at 08:31:02PM +0100, Magnus Lindholm wrote:
> Hi all,
>
> On Wed, Nov 4, 2026 at 7:53 PM Matt Turner <mattst88@gmail.com> wrote:
> >
> > The Alpha kernel series "alpha/perf: add ProfileMe sampling" adds
> > ProfileMe sampling to the Alpha cpu PMU. Each ProfileMe sample carries
> > the profiled instruction's PMPC and its I_STAT and PCTR_CTL status as
> > PERF_SAMPLE_RAW data, which says whether the instruction retired,
> > whether it trapped and why, whether it was a mispredicted branch,
> > stalled before map, or was killed on a wrong path, and what PCTR1
> > counted while it was in flight:
> >
> > https://lore.kernel.org/r/20261104-alpha-profileme-v6-0-63362e9290a3@gmail.com
> >
> > This series is the perf tool side. Patch 1 decodes the raw data in perf
> > report -D and perf script -D, as is done for AMD IBS. It copies the new
> > uapi header from the kernel series into tools/arch, so it should wait
> > until that header is merged. Patch 2 adds a script that sums the status
> > by symbol or by instruction, in the style of DCPI. Patch 3 gives perf
> > mem a ProfileMe event, as the kernel series reports the DTB hits and
> > misses of loads and stores in the data source.
> >
> > To try it, with the kernel series applied:
> >
> > perf record -R -e cpu/instructions,profileme/ -- ./workload
> > tools/perf/python/alpha-profileme.py --pc
> >
> > I tested this on an AlphaServer ES47 (EV7). Sampling a loop whose
> > branch tests random data reports that branch mispredicted in 21% of its
> > samples, and 0% with sorted data. As a normal user, perf mem record on
> > a loop that loads one word from each page reports the load's DTB hits
> > and misses.
> >
> > Signed-off-by: Matt Turner <mattst88@gmail.com>
> > ---
> > Changes in v4:
> > - Patches 1 and 2: ignore TRP, and MIS and the trap type with it, for
> > an instruction killed before it was mapped, as the kernel series
> > does. Thanks to Ian Rogers.
> > - Patch 2: record cpu/instructions,profileme/ in the example, as a
> > precise event now samples only retired instructions, which leaves
> > the killed% and invalid% columns at 0. Thanks to Ian Rogers.
> > - New patch 3: add a perf mem event for Alpha, cpu/cycles,profileme/.
> > Suggested by Ian Rogers.
> > - Link to v3: https://patch.msgid.link/20261102-perf-alpha-profileme-v3-0-4bf6e1dda733@gmail.com
> >
> > Changes in v3:
> > - Patch 1: silence -Wpacked around the uapi header, which breaks the
> > build where __u64 is 4-byte aligned, such as sh4.
> > - Patch 2: only read raw data from cpu PMU events, as a tracepoint's
> > payload can pass for ProfileMe status. Thanks to Magnus Lindholm.
> > - Patch 2: print a table for each thing PCTR1 can count, so that mixing
> > events no longer averages unrelated values. Thanks to Magnus Lindholm.
> > - Link to v2: https://patch.msgid.link/20261030-perf-alpha-profileme-v2-0-9ce2f0b0e622@gmail.com
> >
> > Changes in v2:
> > - Patch 1: copy the raw data out of the sample and convert it from
> > little endian, so that it decodes on strict-alignment and big-endian
> > hosts.
> > - Patches 1 and 2: follow the new 28-byte struct alpha_profileme_sample
> > from kernel v2.
> > - Link to v1: https://patch.msgid.link/20261028-perf-alpha-profileme-v1-0-f46c1938d001@gmail.com
> >
> > ---
> > Matt Turner (3):
> > perf alpha: Decode ProfileMe raw samples
> > perf python: Add alpha-profileme.py
> > perf alpha: Add perf mem support
> >
> > tools/arch/alpha/include/uapi/asm/perf_event.h | 31 +++++
> > tools/perf/Documentation/perf-mem.txt | 3 +
> > tools/perf/arch/alpha/Build | 2 +-
> > tools/perf/arch/alpha/util/Build | 2 +
> > tools/perf/arch/alpha/util/mem-events.c | 17 +++
> > tools/perf/arch/alpha/util/mem-events.h | 7 +
> > tools/perf/arch/alpha/util/pmu.c | 11 ++
> > tools/perf/check-headers.sh | 1 +
> > tools/perf/python/alpha-profileme.py | 178 +++++++++++++++++++++++++
> > tools/perf/util/Build | 1 +
> > tools/perf/util/alpha-sample-raw.c | 156 ++++++++++++++++++++++
> > tools/perf/util/sample-raw.c | 2 +
> > tools/perf/util/sample-raw.h | 2 +
> > 13 files changed, 412 insertions(+), 1 deletion(-)
> > ---
> > base-commit: 4626d370ae89b8af4d46a45372b269f926ec662d
> > change-id: 20261028-perf-alpha-profileme-8010299be323
> >
> > Best regards,
> > --
> > Matt Turner <mattst88@gmail.com>
> >
>
> My plan is to take this series through the Alpha tree alongside the
> kernel ProfileMe support. Does that work for the perf maintainers?
> An Acked-by would be appreciated.
Should be ok as it hardly touches the common code.
Acked-by: Namhyung Kim <namhyung@kernel.org>
Ian, does it look ok to you?
Thanks,
Namhyung
prev parent reply other threads:[~2026-11-11 6:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 18:53 Matt Turner
2026-11-04 18:53 ` [PATCH v4 1/3] perf alpha: Decode ProfileMe raw samples Matt Turner
2026-11-04 18:53 ` [PATCH v4 2/3] perf python: Add alpha-profileme.py Matt Turner
2026-11-04 22:27 ` Magnus Lindholm
2026-11-04 18:53 ` [PATCH v4 3/3] perf alpha: Add perf mem support Matt Turner
2026-11-09 22:51 ` Magnus Lindholm
2026-11-10 19:31 ` [PATCH v4 0/3] perf alpha: Decode ProfileMe samples Magnus Lindholm
2026-11-11 6:25 ` Namhyung Kim [this message]
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=avQKb-vBxTvMn1yF@z2 \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jolsa@kernel.org \
--cc=linmag7@gmail.com \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mattst88@gmail.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
/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
all inboxes | Powered by JetHome®