[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87mszsw25c.ffs@tglx>
Date: Wed, 19 Jul 2023 13:50:55 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Sandipan Das <sandipan.das@....com>, linux-kernel@...r.kernel.org,
linux-perf-users@...r.kernel.org, x86@...nel.org
Cc: peterz@...radead.org, mingo@...hat.com, acme@...nel.org,
mark.rutland@....com, alexander.shishkin@...ux.intel.com,
jolsa@...nel.org, namhyung@...nel.org, irogers@...gle.com,
adrian.hunter@...el.com, bp@...en8.de, dave.hansen@...ux.intel.com,
hpa@...or.com, eranian@...gle.com, ananth.narayan@....com,
ravi.bangoria@....com, santosh.shukla@....com, sandipan.das@....com
Subject: Re: [PATCH 3/6] x86/cpuid: Add smp helper
On Wed, Jul 19 2023 at 09:29, Thomas Gleixner wrote:
> On Wed, Jul 19 2023 at 12:25, Sandipan Das wrote:
>> Depending on which CPU the CPUID instruction is executed, some leaves
>> can report different values. There are cases where it may be required
>> to know all possible values.
>> Add a new helper that executes CPUID on a particular CPU and returns
>> the EAX, EBX, ECX and EDX values.
>
> NAK.
>
> This madness has to stop. The correct thing is to parse the information
> in CPUID at the point where the CPU comes online and store it for easy
> consumption.
>
> I'm in the process of reworking the CPUID and topology evaluation and
> that's where these things need to be stored. I'm still fighting some
> nightmares with the already existing mess.
>
> Look at the mess people created over time here:
>
> https://lore.kernel.org/lkml/20230717223049.327865981@linutronix.de
>
> No need to add more insanities to it. IOW, this has to wait for a week
> or two until I settled the remaining issues.
Actually you can do that today already. Either make it part of the CPUID
evaluation or use the perf hotplug callback mechanism which is invoked
early on the upcoming CPU and read that CPUID leaf.
Powered by blists - more mailing lists