All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Dapeng Mi" <dapeng1.mi@linux.intel.com>
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: Fri, 12 Jun 2026 09:21:41 +0000	[thread overview]
Message-ID: <20260612092141.8AE911F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260612090114.3188886-4-dapeng1.mi@linux.intel.com>

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?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260612090114.3188886-1-dapeng1.mi@linux.intel.com?part=3

  reply	other threads:[~2026-06-12  9:21 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 [this message]
2026-06-15  1:00     ` Mi, Dapeng
2026-06-15  1:03       ` Mi, Dapeng
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=20260612092141.8AE911F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=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.