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

[Pawan Gupta <pawan.kumar.gupta@linux.intel.com>]

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?