Re: [PATCH] perf/x86/amd/lbr: Freeze LBR on PMI only when kernel branches are recorded

[Sandipan Das <sandipan.das@amd.com>]

On 04-11-2026 00:39, Andrii Nakryiko wrote:
> On Mon, Nov 2, 2026 at 2:08 AM Sandipan Das <sandipan.das@amd.com> wrote:
>>
>> On 30-10-2026 01:42, Andrii Nakryiko wrote:
>>> On Fri, Oct 23, 2026 at 5:42 AM Puranjay Mohan <puranjay@kernel.org> wrote:
>>>>
>>>> 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 when branches into the kernel are recorded; without it the
>>>> stack fills with the handler's own branches. A user-only filter does not
>>>> record them, and parts without the feature are never frozen (see commit
>>>> 598c2fafc06f ("perf/x86/amd/lbr: Use freeze based on availability")).
>>>>
>>>> Freeze unless the value written to LBR_SELECT, which is shared by all
>>>> events on the CPU, suppresses branches into the kernel.
>>>>
>>>> With perf record -e ex_ret_brn_tkn:u -j any,u on a Zen 5 part running
>>>> CPython, the function of the sampled IP differs from the function of
>>>> LBR[0].to in 84.3% of samples with the freeze and in 0.1% without it.
>>>>
>>>> Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
>>>> ---
>>>>  arch/x86/events/amd/lbr.c | 9 +++++++--
>>>>  1 file changed, 7 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/x86/events/amd/lbr.c b/arch/x86/events/amd/lbr.c
>>>> index a55646fcb8465..7ec50380ac81d 100644
>>>> --- a/arch/x86/events/amd/lbr.c
>>>> +++ b/arch/x86/events/amd/lbr.c
>>>> @@ -392,7 +392,7 @@ 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_select = 0, dbg_ctl, dbg_extn_cfg;
>>>>
>>>>         if (!cpuc->lbr_users || !x86_pmu.lbr_nr)
>>>>                 return;
>>>> @@ -405,7 +405,12 @@ void amd_pmu_lbr_enable_all(void)
>>>>
>>>>         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);
>>>> +               /* Freeze unless the filter suppresses branches into the kernel */
>>>> +               if (lbr_select & LBR_KERNEL)
>>>
>>> On Intel CPU side, we reset this FREEZE bit in
>>> __intel_pmu_lbr_enable() if is_lbr_call_stack_bit_set(), with the
>>> comment "LBR callstack does not work well with FREEZE_LBRS_ON_PMI.".
>>> So this is not *exactly* what Intel side of things is doing, and I'm
>>> not sure I fully understand the differences, so hopefully someone more
>>> knowledgeable can help.
>>>
>>> But what Puranjay is trying to do here is to at least make a
>>> user-mode-only LBR and IP + callstack to be coherent (for PGO data
>>> collection, which we then use for user space app compilation), by
>>> disabling freezing for LBR.
>>>
>>> It doesn't seem like there is anything we can do on AMD hardware for
>>> when we want kernel-side LBR and precise IP to be in sync,
>>> unfortunately, but at least for user-space only case it would allow us
>>> to not plain disable freezing altogether at kernel boot time.
>>>
>>> Does this approach make sense?
>>>
>>
>> Yes, the intent to keep the LBR and IP coherent is clear. However, my
>> concern is that this may end up dropping the branches preceding the
>> hotspots since a CPU might keep executing in userspace until the PMI
>> handler runs. I'm not sure about the effect that this is going to have
>> on PGO but what if we rely on a mechanism (UAPI + tool flags) to let
>> users explicitly request freeze?
>>
>> If there is an use-case where freeze helps, then the facility can be
>> explicitly requested.
> 
> heh, it's actually the other way, freezing **hurts** consistency
> here... should API requested freeze *opt-out*? because freezing, if
> supported by CPU, currently, is the default behavior not requiring
> opt-in. Or are you proposing to not enable freeze (even if
> cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE) is true), and then
> make user space request freezing with the new UAPI config flag?
> 

The latter. The default will be freeze disabled irrespective of the
CPUID feature bit.

> I'm not against expanding UAPI, but it feels like a very quirky little
> thing which also stems from AMD-only limitation of not supporting
> precise IP capture with LBR enabled
> 

I agree but it can live as an AMD-only flag in perf_event_attr.config2
or something similar and advertised through x86_pmu.format_attrs.

> 
> BTW, the alternative that internal customers actually requested
> initially instead of this was to completely disable freezing at start
> up through the kernel command line. Which seems like the worst
> outcome.
> 
> Thoughts? This all seems unfortunately messy, but hopefully we can
> figure out some non-intrusive but workable solution.
> 
>>
>>>
>>>> +                       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
>>>>
>>