From: Ingo Molnar <mingo@kernel.org>
To: Sandipan Das <sandipan.das@amd.com>
Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
x86@kernel.org, peterz@infradead.org, mingo@redhat.com,
acme@kernel.org, mark.rutland@arm.com,
alexander.shishkin@linux.intel.com, jolsa@kernel.org,
namhyung@kernel.org, adrian.hunter@intel.com, tglx@linutronix.de,
bp@alien8.de, eranian@google.com, irogers@google.com,
mario.limonciello@amd.com, ravi.bangoria@amd.com,
ananth.narayan@amd.com
Subject: Re: [PATCH v3 1/3] perf/x86/amd/lbr: Use freeze based on availability
Date: Wed, 13 Mar 2024 11:15:12 +0100 [thread overview]
Message-ID: <ZfF8sIol5xQcJM9F@gmail.com> (raw)
In-Reply-To: <12f378d5c9459e765c6c3a14b092e6f91da596e3.1706526029.git.sandipan.das@amd.com>
* Sandipan Das <sandipan.das@amd.com> wrote:
> Currently, it is assumed that LBR Freeze is supported on all processors
> which have CPUID leaf 0x80000022[EAX] bit 1 set. This is incorrect as
That's X86_FEATURE_AMD_LBR_V2, right? Should probably be mentioned in the
changelog.
> the feature availability is additionally dependent on CPUID leaf
> 0x80000022[EAX] bit 2 being set which may not be set for all Zen 4
> processors. Define a new feature bit for LBR and PMC freeze and set the
> freeze enable bit (FLBRI) in DebugCtl (MSR 0x1d9) conditionally.
What happens on such Zen 4 CPUs that don't support LBR Freeze? Does the CPU
just ignore it, or something worse?
> It should still be possible to use LBR without freeze for profile-guided
> optimization of user programs by using an user-only branch filter during
> profiling. When the user-only filter is enabled, branches are no longer
> recorded after the transition to CPL 0 upon PMI arrival. When branch
> entries are read in the PMI handler, the branch stack does not change.
>
> E.g.
>
> $ perf record -j any,u -e ex_ret_brn_tkn ./workload
>
> Since the feature bit is visible under flags in /proc/cpuinfo, it can be
> used to determine the feasibility of use-cases which require LBR Freeze
> to be supported by the hardware such as profile-guided optimization of
> kernels.
Sounds good to me.
> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index 4af140cf5719..e47ea31b019d 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -97,7 +97,7 @@
> #define X86_FEATURE_SYSENTER32 ( 3*32+15) /* "" sysenter in IA32 userspace */
> #define X86_FEATURE_REP_GOOD ( 3*32+16) /* REP microcode works well */
> #define X86_FEATURE_AMD_LBR_V2 ( 3*32+17) /* AMD Last Branch Record Extension Version 2 */
> -/* FREE, was #define X86_FEATURE_LFENCE_RDTSC ( 3*32+18) "" LFENCE synchronizes RDTSC */
> +#define X86_FEATURE_AMD_LBR_PMC_FREEZE ( 3*32+18) /* AMD LBR and PMC Freeze */
> #define X86_FEATURE_ACC_POWER ( 3*32+19) /* AMD Accumulated Power Mechanism */
> #define X86_FEATURE_NOPL ( 3*32+20) /* The NOPL (0F 1F) instructions */
> #define X86_FEATURE_ALWAYS ( 3*32+21) /* "" Always-present feature */
Could you please port this to the latest upstream kernel? The 3*32+18 slot
is now used for another purpose, and we need to define a new synthethic
CPUID word, word 21 if I'm counting it right.
Don't forget to increase NCAPINTS from 21 to 22, and consider the fixed
asserts in the x86_bug_flags[] definitions in <asm/cpufeature.h>, and the
asserts in <asm/disabled-features.h> and <asm/required-features.h>. This
new word should probably be added in a separate preparatory patch.
Thanks,
Ingo
next prev parent reply other threads:[~2024-03-13 10:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-29 11:06 [PATCH v3 0/3] perf/x86/amd: Miscellaneous fixes Sandipan Das
2024-01-29 11:06 ` [PATCH v3 1/3] perf/x86/amd/lbr: Use freeze based on availability Sandipan Das
2024-03-13 10:15 ` Ingo Molnar [this message]
2024-03-13 10:26 ` Sandipan Das
2024-01-29 11:06 ` [PATCH v3 2/3] perf/x86/amd/lbr: Discard erroneous branch entries Sandipan Das
2024-01-29 11:06 ` [PATCH v3 3/3] perf/x86/amd/core: Avoid register reset when CPU is dead Sandipan Das
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=ZfF8sIol5xQcJM9F@gmail.com \
--to=mingo@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=ananth.narayan@amd.com \
--cc=bp@alien8.de \
--cc=eranian@google.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=ravi.bangoria@amd.com \
--cc=sandipan.das@amd.com \
--cc=tglx@linutronix.de \
--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;
as well as URLs for NNTP newsgroup(s).