Re: [PATCH PATCH 1/9] x86/cpu/topology: Add x86_cpu_type to struct cpuinfo_topology

Pawan Gupta
2024-06-19T03:31:34Z

On Tue, Jun 18, 2024 at 11:28:01PM +0200, Borislav Petkov wrote:
> On Mon, Jun 17, 2024 at 02:11:26AM -0700, Pawan Gupta wrote:
> > --- a/arch/x86/include/asm/processor.h
> > +++ b/arch/x86/include/asm/processor.h
> > @@ -95,6 +95,9 @@ struct cpuinfo_topology {
> > // Core ID relative to the package
> > u32 core_id;
> >
> > + // CPU-type e.g. performance, efficiency etc.
> > + u8 cpu_type;
> > +
> > // Logical ID mappings
> > u32 logical_pkg_id;
> > u32 logical_die_id;
> > diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
> > index abe3a8f22cbd..b28ad9422afb 100644
> > --- a/arch/x86/include/asm/topology.h
> > +++ b/arch/x86/include/asm/topology.h
> > @@ -41,6 +41,14 @@
> > /* Mappings between logical cpu number and node number */
> > DECLARE_EARLY_PER_CPU(int, x86_cpu_to_node_map);
> >
> > +#define X86_CPU_TYPE_INTEL_SHIFT 24
> > +
> > +enum x86_topo_cpu_type {
> > + X86_CPU_TYPE_UNKNOWN = 0,
> > + X86_CPU_TYPE_INTEL_ATOM = 0x20,
> > + X86_CPU_TYPE_INTEL_CORE = 0x40,
>
> Can we unify those core types and do our own (our == Linux) defines instead of
> using Intels or AMDs?

As Dave pointed out in the other email, atleast mitigations have a use case
to match the raw CPU type defined by the vendor. It could get tricky if
ever there will be different types of performance cores, with different
hardware characteristics.

> There will be AMD variants too soon:
>
> https://lore.kernel.org/r/7aad57a98b37fa5893d4fe602d3dcef5c3f755d5.1718606975.git.perry.yuan@amd.com
>
> so can we have generic defines like
>
> PERF_CORE
> EFF_CORE
> bla_CORE
>
> and so on
>
> ?
>
> And then map each vendor's types to the Linux types?

I am no expert, but I do think generic Linux types could also be useful in
future. Hypothetically speaking, these can be used to make better
scheduling decisions. For example, CPU bound processes can be scheduled
more on performance cores and I/O bound on efficiency cores.

To accommodate for that we can name the vendor specific types in this
series as vendor_cpu_type. And if we ever need to add generic types, we can
call them cpu_type?