From: Puranjay Mohan <puranjay@kernel.org>
To: Sandipan Das <sandipan.das@amd.com>,
Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
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>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
James Clark <james.clark@linaro.org>,
Thomas Gleixner <tglx@kernel.org>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
Andrii Nakryiko <andrii@kernel.org>
Subject: [PATCH RFC] perf/x86/amd/lbr: Don't freeze the LBR on PMI for user-only filters
Date: Thu, 5 Nov 2026 09:03:40 -0800 [thread overview]
Message-ID: <20261105170340.165507-1-puranjay@kernel.org> (raw)
In-Reply-To: <b7456dbb-16fd-45b4-8742-e9ea3f896317@amd.com>
On CPUs with X86_FEATURE_AMD_LBR_PMC_FREEZE the LBR is always frozen on
PMI, so the branch stack ends before the IP and callchain, which are
taken when the NMI is delivered. IBS rejects branch-stack events, so
there is no precise alternative.
The freeze only keeps the PMI handler's branches out of the stack, which
matters only if branches into the kernel are recorded. Skip it when
LBR_SELECT suppresses them, and add a freeze format bit (config2:0) to
request it anyway.
Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
---
Thanks both. A user-only default with an explicit request works for me,
with one exception I would like to keep: when branches into the kernel
are recorded the freeze has to stay. On a Zen 5 part with the freeze
cleared and a user+kernel filter, every entry in every sample was a
branch taken by amd_pmu_v2_handle_irq() or amd_pmu_lbr_read(), so users
recording kernel branches would regress with a "never freeze" default.
This RFC does the following:
- LBR_SELECT suppresses kernel branches: no freeze, unless the new
AMD-only freeze format bit (config2:0, advertised through the format
attributes) is set.
- Otherwise: freeze as today.
That needs no tool changes for the user-only case and gives an explicit
way to request the freeze. This version is only compile tested; I will
retest on a Zen 5 part if the approach is acceptable.
arch/x86/events/amd/core.c | 14 ++++++++++++++
arch/x86/events/amd/lbr.c | 21 ++++++++++++++++++---
2 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
index 49b6b8fce5664..d63649c756a58 100644
--- a/arch/x86/events/amd/core.c
+++ b/arch/x86/events/amd/core.c
@@ -1404,8 +1404,22 @@ static struct attribute_group group_events_amd_brs = {
#endif /* CONFIG_PERF_EVENTS_AMD_BRS */
+PMU_FORMAT_ATTR(freeze, "config2:0");
+
+static struct attribute *amd_pmu_lbr_format_attrs[] = {
+ &format_attr_freeze.attr,
+ NULL,
+};
+
+static struct attribute_group group_format_amd_lbr = {
+ .name = "format",
+ .attrs = amd_pmu_lbr_format_attrs,
+ .is_visible = amd_branches_is_visible,
+};
+
static const struct attribute_group *amd_attr_update[] = {
&group_caps_amd_branches,
+ &group_format_amd_lbr,
#ifdef CONFIG_PERF_EVENTS_AMD_BRS
&group_events_amd_brs,
#endif
diff --git a/arch/x86/events/amd/lbr.c b/arch/x86/events/amd/lbr.c
index a55646fcb8465..f45e2c53566af 100644
--- a/arch/x86/events/amd/lbr.c
+++ b/arch/x86/events/amd/lbr.c
@@ -10,6 +10,12 @@
/* LBR Branch Select valid bits */
#define LBR_SELECT_MASK 0x1ff
+/* attr.config2: freeze the LBR on PMI */
+#define LBR_CFG2_FREEZE BIT_ULL(0)
+
+/* Software only, masked out before writing LBR_SELECT */
+#define LBR_FREEZE BIT_ULL(63)
+
/*
* LBR Branch Select filter bits which when set, ensures that the
* corresponding type of branches are not recorded
@@ -307,6 +313,9 @@ static int amd_pmu_lbr_setup_filter(struct perf_event *event)
/* Filter bits operate in suppress mode */
reg->config = mask ^ LBR_SELECT_MASK;
+ if (event->attr.config2 & LBR_CFG2_FREEZE)
+ reg->config |= LBR_FREEZE;
+
return 0;
}
@@ -392,20 +401,26 @@ void amd_pmu_lbr_sched_task(struct perf_event_pmu_context *pmu_ctx,
void amd_pmu_lbr_enable_all(void)
{
struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
- u64 lbr_select, dbg_ctl, dbg_extn_cfg;
+ u64 lbr_cfg = 0, lbr_select = 0, dbg_ctl, dbg_extn_cfg;
if (!cpuc->lbr_users || !x86_pmu.lbr_nr)
return;
/* Set hardware branch filter */
if (cpuc->lbr_select) {
- lbr_select = cpuc->lbr_sel->config & LBR_SELECT_MASK;
+ lbr_cfg = cpuc->lbr_sel->config;
+ lbr_select = lbr_cfg & LBR_SELECT_MASK;
wrmsrq(MSR_AMD64_LBR_SELECT, lbr_select);
}
if (cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE)) {
rdmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl);
- wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl | DEBUGCTLMSR_FREEZE_LBRS_ON_PMI);
+ /* Skip the freeze if kernel branches are suppressed, unless asked */
+ if ((lbr_select & LBR_KERNEL) && !(lbr_cfg & LBR_FREEZE))
+ dbg_ctl &= ~DEBUGCTLMSR_FREEZE_LBRS_ON_PMI;
+ else
+ dbg_ctl |= DEBUGCTLMSR_FREEZE_LBRS_ON_PMI;
+ wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl);
}
rdmsrq(MSR_AMD_DBG_EXTN_CFG, dbg_extn_cfg);
base-commit: 0f443787a7f6ae907975742680aac2600483eaf1
--
2.53.0-Meta
next prev parent reply other threads:[~2026-11-05 17:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-23 12:41 [PATCH] perf/x86/amd/lbr: Freeze LBR on PMI only when kernel branches are recorded Puranjay Mohan
2026-10-26 15:35 ` Sandipan Das
2026-10-29 20:12 ` Andrii Nakryiko
2026-11-02 10:08 ` Sandipan Das
2026-11-03 19:09 ` Andrii Nakryiko
2026-11-05 6:17 ` Sandipan Das
2026-11-05 16:58 ` Andrii Nakryiko
2026-11-05 17:03 ` Puranjay Mohan [this message]
2026-11-06 1:07 ` [PATCH RFC] perf/x86/amd/lbr: Don't freeze the LBR on PMI for user-only filters Andrii Nakryiko
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=20261105170340.165507-1-puranjay@kernel.org \
--to=puranjay@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=sandipan.das@amd.com \
--cc=tglx@kernel.org \
--cc=x86@kernel.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®