[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f71aff95-3aea-4681-9d35-9847b086cc8e@amd.com>
Date: Tue, 3 Dec 2024 16:02:29 -0600
From: Mario Limonciello <mario.limonciello@....com>
To: Borislav Petkov <bp@...en8.de>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
"H . Peter Anvin" <hpa@...or.com>,
"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<linux-kernel@...r.kernel.org>, Perry Yuan <Perry.Yuan@....com>,
Shyam Sundar S K <Shyam-sundar.S-k@....com>
Subject: Re: [PATCH v2] x86/cpu: Enable SD_ASYM_PACKING for PKG domain on
systems with AMD preferred cores
On 12/3/2024 15:54, Borislav Petkov wrote:
> On Tue, Dec 03, 2024 at 02:11:29PM -0600, Mario Limonciello wrote:
>> For the scheduler to use and prefer AMD preferred core rankings set
>> SD_ASYM_PACKING for x86_die_flags().
>>
>> Signed-off-by: Mario Limonciello <mario.limonciello@....com>
>> ---
>> v2:
>> * Fix c23 compatibility issue reported by LKP
>> ---
>> arch/x86/kernel/smpboot.c | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
>> index b5a8f0891135b..6a38cf3feb1a9 100644
>> --- a/arch/x86/kernel/smpboot.c
>> +++ b/arch/x86/kernel/smpboot.c
>> @@ -62,6 +62,8 @@
>> #include <linux/mc146818rtc.h>
>> #include <linux/acpi.h>
>>
>> +#include <acpi/cppc_acpi.h>
>> +
>> #include <asm/acpi.h>
>> #include <asm/cacheinfo.h>
>> #include <asm/desc.h>
>> @@ -501,6 +503,15 @@ static int x86_die_flags(void)
>> cpu_feature_enabled(X86_FEATURE_AMD_HETEROGENEOUS_CORES))
>> return x86_sched_itmt_flags();
>>
>> + if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
>> + boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
>
> You're going to call this on *every* AMD and on Hygon?
>
> So that whole effort with X86_FEATURE_s was for nothing?
>
> What's up?
>
Preferred core classifications are available on "non-heterogenous"
designs for a few generations. There isn't an indication they're
supported which is why amd_detect_prefcore() was made.
That's already called during the boot either way because that is used
to identify the boost numerator. The boolean value it finds is cached,
and the next call will use the cached value. So I don't expect this
change affects boot speed.
Powered by blists - more mailing lists