On 10/22/2024 11:03, Dave Hansen wrote:
On 10/22/24 04:57, Borislav Petkov wrote:
+enum x86_topology_cpu_type get_intel_cpu_type(struct cpuinfo_x86 *c)
+{
+ switch (c->topo.intel_type) {
+ case 0x20: return TOPO_CPU_TYPE_EFFICIENCY;
+ case 0x40: return TOPO_CPU_TYPE_PERFORMANCE;
+ }
+ return TOPO_CPU_TYPE_UNKNOWN;
+}
This makes me feel a _bit_ uneasy. 0x20 here really does mean "Atom
microarchitecture" and 0x40 means "Core microarchitecture".
We want to encourage folks to use this new ABI when they want to find
the fastest core to run on. But we don't want them to use it to bind to
a CPU and then deploy Atom-specific optimizations.
We *also* don't want the in-kernel code to do be doing things like:
if (get_intel_cpu_type() == TOPO_CPU_TYPE_EFFICIENCY)
setup_force_cpu_bug(FOO);
That would fall over if Intel ever mixed fast and slow core types with
the same microarchitecture, which is what AMD is doing today.
Having:
TOPO_CPU_TYPE_EFFICIENCY, and
TOPO_CPU_TYPE_PERFORMANCE
is totally fine in generic code. But we also need to preserve the:
TOPO_HW_CPU_TYPE_INTEL_ATOM
TOPO_HW_CPU_TYPE_INTEL_CORE
values also for use in vendor-specific code.
What you're suggesting is to keep an enum in the intel.c code and any
code that needs to match atom vs core can directly use
c->topo.intel_type == TOPO_HW_CPU_TYPE_INTEL_ATOM
Right?
In the ABI, I think we should probably make this an explicit
power/performance interface rather than "cpu_type". As much as I like
the human readable "performance" and "efficiency", I'm worried it won't
be flexible enough for future maniacal hardware designers. To be 100%
clear, all the hardware designs that I know of would fit in a two-bucket
("performance" and "efficiency") scheme. But we've got to decide
whether to commit to that forever.
As it stands today none of this is exported anywhere but debugfs; so I
wouldn't say we have ABI concerns (yet). Could we wait until the one
that breaks the mold shows up?
