[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87v8egwe9l.ffs@tglx>
Date: Wed, 19 Jul 2023 09:29:10 +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 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.
>
> E.g. for AMD Zen 4 processors, the ActiveUmcMask field from leaf
> 0x80000022 ECX, which provides a way to determine the active memory
> controllers, can have different masks on CPUs belonging to different
> sockets as each socket can follow a different DIMM population scheme.
> Each memory channel is assigned a memory controller (UMC) and if no
> DIMMs are attached to a channel, the corresponding memory controller
> is inactive. There are performance monitoring counters exclusive to
> each memory controller which need to be represented under separate
> PMUs. So, it will be necessary to know the active memory controllers
> on each socket during the initialization of the UMC PMUs irrespective
> of where the uncore driver's module init runs.
>
> 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.
Thanks
tglx
Powered by blists - more mailing lists