From: Matt Turner <mattst88@gmail.com>
To: Madhavan Srinivasan <maddy@linux.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
Paul Mackerras <paulus@ozlabs.org>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Matt Turner <mattst88@gmail.com>
Subject: [PATCH 7/8] powerpc/perf: Use SIAR for sample addresses on 32-bit
Date: Mon, 09 Nov 2026 20:47:06 -0500 [thread overview]
Message-ID: <20261109-ppc32-perf-v1-7-a6e8a55b3b48@gmail.com> (raw)
In-Reply-To: <20261109-ppc32-perf-v1-0-a6e8a55b3b48@gmail.com>
On 32-bit, perf_read_regs() sets regs->result to 0, so regs_use_siar()
is always false and every sample is attributed to the interrupted PC.
The MPC7450 family's SIAR holds the address of the last instruction to
complete before the performance monitor exception is generated
(MPC7450UM Rev. 5, section 11.3.7). The exception can be generated
with MSR[EE] = 0 and is taken once EE is set again (section 11.2), so
when interrupts are disabled the interrupted PC is wherever they are
re-enabled, while SIAR still points into the disabled region.
On a 7448, sampling cycles system-wide with --intr-regs=nip during dd,
perf bench sched pipe and find, 46% of the kernel samples have SIAR and
the interrupted PC in different functions. 13270 samples have their PC
on the instruction after the mtmsr that restores interrupts in
ata_scsi_queuecmd(), and 11661 of those have SIAR in udelay().
With interrupts enabled SIAR helps less. Sampling a 32-instruction
loop with one store and one branch with -c 10007, 99.8% of the samples
land at:
event interrupted PC SIAR
r122 (branches) br + 13 br + 9
r014 (stores) stw + 21 stw + 17
siar_valid() already returns true on 32-bit. Use SIAR for PMU
exceptions, and take the user/kernel flags from it too. Move
regs_use_siar() above the 32-bit block so that perf_get_misc_flags()
can call it.
Signed-off-by: Matt Turner <mattst88@gmail.com>
---
arch/powerpc/perf/core-book3s.c | 55 +++++++++++++++++++++++++++--------------
1 file changed, 36 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 10ded865583c..e4c8ecddccbd 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -75,6 +75,20 @@ static struct power_pmu *ppmu;
*/
static unsigned int freeze_events_kernel = MMCR0_FCS;
+static bool regs_use_siar(struct pt_regs *regs)
+{
+ /*
+ * When we take a performance monitor exception the regs are setup
+ * using perf_read_regs() which overloads some fields, in particular
+ * regs->result to tell us whether to use SIAR.
+ *
+ * However if the regs are from another exception, eg. a syscall, then
+ * they have not been setup using perf_read_regs() and so regs->result
+ * is something random.
+ */
+ return ((TRAP(regs) == INTERRUPT_PERFMON) && regs->result);
+}
+
/*
* 32-bit doesn't have MMCRA but does have an MMCR2,
* and a few other names are different.
@@ -108,13 +122,30 @@ static inline unsigned long perf_ip_adjust(struct pt_regs *regs)
return 0;
}
static inline void perf_get_data_addr(struct perf_event *event, struct pt_regs *regs, u64 *addrp) { }
-static inline u32 perf_get_misc_flags(struct pt_regs *regs)
-{
- return 0;
-}
+
+/*
+ * The MPC7450 family's SIAR holds the address of the last instruction to
+ * complete before the performance monitor exception was generated, so for
+ * a PMU exception it is closer to the event than the interrupted PC.
+ */
static inline void perf_read_regs(struct pt_regs *regs)
{
- regs->result = 0;
+ regs->result = 1;
+}
+
+static inline u32 perf_get_misc_flags(struct pt_regs *regs)
+{
+ unsigned long siar;
+
+ if (!regs_use_siar(regs))
+ return 0;
+
+ siar = mfspr(SPRN_SIAR);
+ if (!siar)
+ return 0;
+
+ return is_kernel_addr(siar) ? PERF_RECORD_MISC_KERNEL :
+ PERF_RECORD_MISC_USER;
}
static inline int siar_valid(struct pt_regs *regs)
@@ -163,20 +194,6 @@ unsigned long get_pmcs_ext_regs(int idx)
return cpuhw->pmcs[idx];
}
-static bool regs_use_siar(struct pt_regs *regs)
-{
- /*
- * When we take a performance monitor exception the regs are setup
- * using perf_read_regs() which overloads some fields, in particular
- * regs->result to tell us whether to use SIAR.
- *
- * However if the regs are from another exception, eg. a syscall, then
- * they have not been setup using perf_read_regs() and so regs->result
- * is something random.
- */
- return ((TRAP(regs) == INTERRUPT_PERFMON) && regs->result);
-}
-
/*
* Things that are specific to 64-bit implementations.
*/
--
2.55.0
next prev parent reply other threads:[~2026-11-10 1:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 1:46 [PATCH 0/8] powerpc/perf: mpc7450: Event fixes, SIAR sampling and sysfs event names Matt Turner
2026-11-10 1:47 ` [PATCH 1/8] powerpc/perf: mpc7450: Event 0x30d does not use the threshold Matt Turner
2026-11-10 1:47 ` [PATCH 2/8] powerpc/perf: mpc7450: Event 0x634 counts L2 prefetches, not L1I Matt Turner
2026-11-10 1:47 ` [PATCH 3/8] powerpc/perf: mpc7450: Remove the snoop retry alternatives Matt Turner
2026-11-10 1:47 ` [PATCH 4/8] powerpc/perf: mpc7450: Fill in the L1 data cache events Matt Turner
2026-11-10 1:47 ` [PATCH 5/8] powerpc/perf: mpc7450: Add the PMC6 L3 events to the alternatives table Matt Turner
2026-11-10 1:47 ` [PATCH 6/8] powerpc/perf: mpc7450: Export the event format in sysfs Matt Turner
2026-11-10 1:47 ` Matt Turner [this message]
2026-11-10 1:47 ` [PATCH 8/8] powerpc/perf: mpc7450: Export event names " Matt Turner
2026-11-10 1:55 ` [PATCH 0/8] powerpc/perf: mpc7450: Event fixes, SIAR sampling and sysfs event names Matt Turner
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=20261109-ppc32-perf-v1-7-a6e8a55b3b48@gmail.com \
--to=mattst88@gmail.com \
--cc=chleroy@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=paulus@ozlabs.org \
--cc=ritesh.list@gmail.com \
--cc=sshegde@linux.ibm.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
all inboxes | Powered by JetHome®