From: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>
To: sashiko-reviews@lists.linux.dev
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [Patch v3 3/8] perf/x86/intel: Fallback to sw branch type decoding if no hw decoding
Date: Mon, 15 Jun 2026 09:03:52 +0800 [thread overview]
Message-ID: <15ba38bf-b264-4fc8-8d78-92aeb2d5cce6@linux.intel.com> (raw)
In-Reply-To: <af0e50c4-8ea3-4f10-a2c0-5e3a0427107a@linux.intel.com>
On 6/15/2026 9:00 AM, Mi, Dapeng wrote:
> On 6/12/2026 5:21 PM, sashiko-bot@kernel.org wrote:
>> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>> - [High] The patch introduces a severe performance regression in NMI context on Arch LBR CPUs that lack hardware branch-type decoding by unintentionally forcing software disassembly on all recorded branches.
>> --
>>
>> commit 4686077e19d211c998cc542c03a674a17408e8d7
>> Author: Dapeng Mi <dapeng1.mi@linux.intel.com>
>>
>> perf/x86/intel: Fallback to sw branch type decoding if no hw decoding
>>
>> This commit updates the arch-LBR filtering logic to fallback to software
>> branch-type decoding if hardware decoding is not supported. It replaces
>> the X86_FEATURE_ARCH_LBR CPU feature check with the x86_lbr_type static
>> branch to properly handle arch-LBR configurations that lack branch-type
>> information.
>>
>>> diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
>>> index 72f2adcda7c68..e2657f791e507 100644
>>> --- a/arch/x86/events/intel/lbr.c
>>> +++ b/arch/x86/events/intel/lbr.c
>>> @@ -1231,7 +1231,7 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc)
>>> * Doesn't support OTHER_BRANCH decoding for now.
>>> * OTHER_BRANCH branch type still rely on software decoding.
>>> */
>>> - if (static_cpu_has(X86_FEATURE_ARCH_LBR) &&
>>> + if (static_branch_likely(&x86_lbr_type) &&
>>> type <= ARCH_LBR_BR_TYPE_KNOWN_MAX) {
>>> to_plm = kernel_ip(to) ? X86_BR_KERNEL : X86_BR_USER;
>>> type = arch_lbr_br_type_map[type] | to_plm;
>> [Severity: High]
>> Does this introduce a performance regression in NMI context on arch-LBR CPUs
>> that lack hardware branch-type decoding?
>>
>> Currently, intel_pmu_setup_hw_lbr_filter() unconditionally sets
>> X86_BR_TYPE_SAVE for arch-LBR CPUs:
>>
>> arch/x86/events/intel/lbr.c:intel_pmu_setup_hw_lbr_filter() {
>> ...
>> reg->reg |= X86_BR_TYPE_SAVE;
>> ...
>> }
>>
>> Because X86_BR_TYPE_SAVE is forcibly set in br_sel, the fast-path early
>> return at the start of intel_pmu_lbr_filter() is bypassed even if the user
>> only requested basic branch recording without branch types.
>>
>> With this patch, if x86_lbr_type is false, the loop falls through to the
>> else block and calls branch_type() for every LBR entry. This causes
>> expensive software instruction decoding to unconditionally execute for all
>> LBR records on every PMU interrupt.
>>
>> Should intel_pmu_setup_hw_lbr_filter() be updated to only force-enable
>> X86_BR_TYPE_SAVE if static_branch_likely(&x86_lbr_type) is true?
> AMD guys have known the issue, they would post the fix separately. Thanks.
Please ignore this comment, it should be the comment for next patch. Thanks.
>
>
>
next prev parent reply other threads:[~2026-06-15 1:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-12 9:01 [Patch v3 0/8] perf/x86: Miscellaneous PMU bug fixes Dapeng Mi
2026-06-12 9:01 ` [Patch v3 1/8] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities Dapeng Mi
2026-06-12 9:46 ` Peter Zijlstra
2026-06-15 0:59 ` Mi, Dapeng
2026-06-15 3:28 ` Mi, Dapeng
2026-06-12 9:01 ` [Patch v3 2/8] perf/x86/intel: Keep cap_user_rdpmc in sync with RDPMC user-disable state Dapeng Mi
2026-06-12 9:01 ` [Patch v3 3/8] perf/x86/intel: Fallback to sw branch type decoding if no hw decoding Dapeng Mi
2026-06-12 9:21 ` sashiko-bot
2026-06-15 1:00 ` Mi, Dapeng
2026-06-15 1:03 ` Mi, Dapeng [this message]
2026-06-12 9:01 ` [Patch v3 4/8] perf/x86/intel: Fix kernel address leakages in LBR stack Dapeng Mi
2026-06-12 9:18 ` sashiko-bot
2026-06-15 1:01 ` Mi, Dapeng
2026-06-12 9:01 ` [Patch v3 5/8] perf/x86/intel: Validate the return value of intel_pmu_init_hybrid() Dapeng Mi
2026-06-12 9:31 ` sashiko-bot
2026-06-15 1:08 ` Mi, Dapeng
2026-06-12 9:01 ` [Patch v3 6/8] perf/x86/intel: Drop fixed-counter PEBS constraints for baseline PEBS Dapeng Mi
2026-06-12 9:01 ` [Patch v3 7/8] perf/core: Fix kernel register info leak via hardware skid Dapeng Mi
2026-06-12 9:01 ` [Patch v3 8/8] perf/core: Check kernel access when kernel callchains are requested Dapeng Mi
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=15ba38bf-b264-4fc8-8d78-92aeb2d5cce6@linux.intel.com \
--to=dapeng1.mi@linux.intel.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.