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: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 18:53 [PATCH v4 0/3] perf alpha: Decode ProfileMe samples Matt Turner
2026-11-04 18:53 ` [PATCH v4 1/3] perf alpha: Decode ProfileMe raw samples Matt Turner
2026-11-04 19:04 ` sashiko-bot
2026-11-04 18:53 ` [PATCH v4 2/3] perf python: Add alpha-profileme.py Matt Turner
2026-11-04 19:08 ` sashiko-bot
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-04 19:14 ` sashiko-bot
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 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.