Re: [PATCH v5 00/11] alpha/perf: add ProfileMe sampling

From: Matt Turner

Date: Wed Nov 04 2026 - 14:38:02 EST


On Tue, Nov 3, 2026 at 6:42 PM Ian Rogers <irogers@xxxxxxxxxx> wrote:
> Patch 5: I think Sashiko's report is right. With idx forced to 0 in
> ProfileMe mode, a PCTR1 overflow still pending when an Aggregate event
> is multiplexed out gets taken as a window close: it adds a bogus 2^20
> to the count and emits a sample from a stale PMPC, possibly another
> task's. That's the mirror image of the false sample the commit message
> documents for the other direction.
>
> In both cases the interrupt arrives for a counter that hasn't wrapped
> since it was last written, whereas after a real overflow or window
> close the counter sits just past zero. Could the handler drop an
> interrupt when the counter hasn't wrapped relative to prev_count? It
> would need some headroom: a counting event's period is 2^20 - 1, so
> its counter starts at 1, and a real overflow, which leaves it just
> past zero, would look unwrapped too. Capping left at half the counter
> range, as armpmu_event_set_period() does, keeps the two cases apart.
> That would fix both directions, and the caveat could come out of the
> commit message.

Agreed, and done in v6 as you describe. It's a separate patch ahead of
the ProfileMe one, since Aggregate mode has the same problem when an
event is reloaded or perf moves another event onto the counter. The
cost is that counting events now interrupt every 2^19 events instead
of every 2^20. The caveat is gone from the ProfileMe commit message.

> Patch 9: Now that patch 11 drops DTB miss samples from cycles:p, it
> may be worth giving retired loads and stores a data source too.

Done. Retired loads and stores without a DTB miss trap get
PERF_MEM_TLB_L1 | PERF_MEM_TLB_HIT. LDA and LDAH aren't memory
instructions, so they get nothing, and neither does the ldq_u UNOP.

> Loads into $31/$f31 need care either way. [...] Running your
> one-word-per-page test with loads into $31 would show which.

I ran it. On the EV7 a load into $31 that misses the DTB does take the
miss trap, so it shows up with TRP set like an ordinary load. Those are
now reported as PERF_MEM_OP_PFETCH, both misses and hits.

One thing the test showed that I didn't expect: an ordinary load's
samples split about 1:1 between DTB misses and hits. The miss trap
aborts the load, PALcode fills the DTB, and the refetched load hits and
gets sampled again. The commit message says so.

> Patch 11: Kept samples still carry the full period, so with -F the
> sample rate, and perf report's approximate event count, fall by the
> killed fraction: to about a third on your mispredict loop. That seems
> the right trade-off, and it's what IBS's swfilt does with the samples
> it discards, but it may deserve a sentence in the commit message.

Added.

> For the next spin of the tools series, alpha-profileme.py wants the
> same PM_KILLED_BM check before it trusts TRP and MIS. Its example also
> records instructions:p, which after patch 11 has no killed samples, so
> the killed% and invalid% columns would always read 0;
> cpu/instructions,profileme/ keeps them.

Both fixed in tools v4, in the script and in the perf report -D
decoder.

> Two possible follow-ups, neither of which needs to hold up this
> series. perf mem has no Alpha events yet; cpu/cycles,trapped/p would
> be a natural default, or cpu/cycles,profileme/ if retired accesses get
> a data source.

Since retired accesses now get one, tools v4 adds a mem-ldst event of
cpu/cycles,profileme/, set up only when the PMU has the profileme
format bit. cycles:p would lose the DTB misses, since it samples only
retired instructions. perf mem record and report work as a normal user
on the EV7, with the load showing both L1 hits and misses in the TLB
column.

> And as the driver already works out the profiled
> instruction's mode for the trap frame swap, ProfileMe events could
> honor exclude_user and exclude_kernel by dropping samples, as IBS's
> swfilt does, with PALmode counting as kernel.

Done as a new last patch in v6. PERF_PMU_CAP_NO_EXCLUDE is gone, and
event_init rejects the exclude bits for Aggregate events, plus
exclude_idle, exclude_guest and exclude_host for all events.
exclude_hv is ignored, as IBS does. A sample that falls back to the
interrupted PC (a PALmode PMPC, or a user PMPC in a kernel thread) is
dropped if either its PC or the profiled instruction is in an excluded
mode, so a user-only event never sees a kernel address. As with IBS,
the event count and the PCTR1 window count still include kernel time.

With perf_event_paranoid at 2, perf record as a normal user now works,
and on a workload with plenty of syscalls none of the samples were in
the kernel. As root, cycles:pu and cycles:pk split the samples cleanly,
and perf stat -e cycles:u still gets EINVAL.

I've sent v6 with these changes.