linux-kernel - Re: [PATCH 03/20] perf/x86/intel: Parse CPUID archPerfmonExt leaves for non-hybrid CPUs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bc002854-85b8-4f55-a253-791d5f222620@linux.intel.com>
Date: Thu, 6 Feb 2025 10:09:31 +0800
From: "Mi, Dapeng" <dapeng1.mi@...ux.intel.com>
To: Peter Zijlstra <peterz@...radead.org>,
 "Liang, Kan" <kan.liang@...ux.intel.com>
Cc: Andi Kleen <ak@...ux.intel.com>, Ingo Molnar <mingo@...hat.com>,
 Arnaldo Carvalho de Melo <acme@...nel.org>,
 Namhyung Kim <namhyung@...nel.org>, Ian Rogers <irogers@...gle.com>,
 Adrian Hunter <adrian.hunter@...el.com>,
 Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
 Eranian Stephane <eranian@...gle.com>, linux-kernel@...r.kernel.org,
 linux-perf-users@...r.kernel.org, Dapeng Mi <dapeng1.mi@...el.com>
Subject: Re: [PATCH 03/20] perf/x86/intel: Parse CPUID archPerfmonExt leaves
 for non-hybrid CPUs


On 1/28/2025 12:44 AM, Peter Zijlstra wrote:
> On Mon, Jan 27, 2025 at 10:19:34AM -0500, Liang, Kan wrote:
>>
>> On 2025-01-23 1:58 p.m., Andi Kleen wrote:
>>>> +	/*
>>>> +	 * The archPerfmonExt (0x23) includes an enhanced enumeration of
>>>> +	 * PMU architectural features with a per-core view. For non-hybrid,
>>>> +	 * each core has the same PMU capabilities. It's good enough to
>>>> +	 * update the x86_pmu from the booting CPU. For hybrid, the x86_pmu
>>>> +	 * is used to keep the common capabilities. Still keep the values
>>>> +	 * from the leaf 0xa. The core specific update will be done later
>>>> +	 * when a new type is online.
>>>> +	 */
>>>> +	if (!is_hybrid() && boot_cpu_has(X86_FEATURE_ARCH_PERFMON_EXT))
>>>> +		update_pmu_cap(NULL);
>>> It seems ugly to have these different code paths. Couldn't non hybrid
>>> use x86_pmu in the same way? I assume it would be a larger patch.
>> The current non-hybrid is initialized in the intel_pmu_init(). But some
>> of the initialization code for the hybrid is in the
>> intel_pmu_cpu_starting(). Yes, it's better to move it together. It
>> should be a larger patch. Since it's impacted other features, a separate
>> patch set should be required.
> IIRC the problem was that there were SKUs with the same FMS that were
> both hybrid and non-hybrid and we wouldn't know until we brought up the
> CPUs.
>
> Thomas rewrote the topology bits since, so maybe we can do beter these
> days.

This optimization would be a fundamental and large change. As Kan said,
we'd better put it as a separate patch series, then it won't block this
arch-PEBS enabling patches.