| Message ID | 20240617-add-cpu-type-v1-0-b88998c01e76@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add CPU-type to topology | expand |
Le 17/06/2024 à 11:11, Pawan Gupta a écrit : > Hi, > > This series adds support for CPU-type (CPUID.1A.EAX[31-24] on Intel) to > differentiate between hybrid variants P+E, P-only, E-only that share the > same Family/Model/Stepping. One of the use case for CPU-type is the > affected CPU table for CPU vulnerabilities, which can now use the CPU-type > to filter the unaffected variants. > > * Patch 1 adds cpu-type to CPU topology structure and introduces > topology_cpu_type() to get the CPU-type. > > * Patch 2-4 replaces usages of get_this_hybrid_cpu_type() with > topology_cpu_type(). > > * Patch 5-7 Updates CPU-matching infrastructure to use CPU-type. > > * Patch 8 cleans up the affected CPU list. > > * Patch 9 uses the CPU-type to exclude P-only parts from the RFDS affected > list. Hello Is there still a plan to expose this info in sysfs? Userspace currently uses frequencies to guess which cores are E or P. Intel sent some patches several years ago [1], but they got abandoned nowhere as far as I know. There was also some discussion about using a "capacity" field like ARM does, but IIRC Intel didn't like the idea in the end. Thanks Brice [1] https://lkml.org/lkml/2020/10/2/1208
On Tue, Jun 18, 2024 at 02:49:10PM +0200, Brice Goglin wrote: > Le 17/06/2024 à 11:11, Pawan Gupta a écrit : > > Hi, > > > > This series adds support for CPU-type (CPUID.1A.EAX[31-24] on Intel) to > > differentiate between hybrid variants P+E, P-only, E-only that share the > > same Family/Model/Stepping. One of the use case for CPU-type is the > > affected CPU table for CPU vulnerabilities, which can now use the CPU-type > > to filter the unaffected variants. > > > > * Patch 1 adds cpu-type to CPU topology structure and introduces > > topology_cpu_type() to get the CPU-type. > > > > * Patch 2-4 replaces usages of get_this_hybrid_cpu_type() with > > topology_cpu_type(). > > > > * Patch 5-7 Updates CPU-matching infrastructure to use CPU-type. > > > > * Patch 8 cleans up the affected CPU list. > > > > * Patch 9 uses the CPU-type to exclude P-only parts from the RFDS affected > > list. > > > Hello > > Is there still a plan to expose this info in sysfs? Sure, if it helps userspace. > Userspace currently uses frequencies to guess which cores are E or P. > Intel sent some patches several years ago [1], but they got abandoned > nowhere as far as I know. There was also some discussion about using a > "capacity" field like ARM does, but IIRC Intel didn't like the idea in > the end. There can be many ways to expose this information in sysfs. Like this ... > [1] https://lkml.org/lkml/2020/10/2/1208 ... exposes /sys/devices/system/cpu/types which, in hybrid parts, creates a subdirectory for each type of CPU. Each subdirectory contains a CPU list and a CPU map that user space can query. The other way is to expose the CPU-type in a file: /sys/devices/system/cpu/cpuN/type that could return the CPU-type of the CPU N. Is there a preference?
On Tue, 2024-06-18 at 18:53 -0700, Pawan Gupta wrote: > On Tue, Jun 18, 2024 at 02:49:10PM +0200, Brice Goglin wrote: > > Le 17/06/2024 à 11:11, Pawan Gupta a écrit : > > > Hi, > > > > > > This series adds support for CPU-type (CPUID.1A.EAX[31-24] on > > > Intel) to > > > differentiate between hybrid variants P+E, P-only, E-only that > > > share the > > > same Family/Model/Stepping. One of the use case for CPU-type is > > > the > > > affected CPU table for CPU vulnerabilities, which can now use the > > > CPU-type > > > to filter the unaffected variants. > > > > > > * Patch 1 adds cpu-type to CPU topology structure and introduces > > > topology_cpu_type() to get the CPU-type. > > > > > > * Patch 2-4 replaces usages of get_this_hybrid_cpu_type() with > > > topology_cpu_type(). > > > > > > * Patch 5-7 Updates CPU-matching infrastructure to use CPU-type. > > > > > > * Patch 8 cleans up the affected CPU list. > > > > > > * Patch 9 uses the CPU-type to exclude P-only parts from the RFDS > > > affected > > > list. > > > > > > Hello > > > > Is there still a plan to expose this info in sysfs? > > Sure, if it helps userspace. > > > Userspace currently uses frequencies to guess which cores are E or > > P. > > Intel sent some patches several years ago [1], but they got > > abandoned > > nowhere as far as I know. There was also some discussion about > > using a > > "capacity" field like ARM does, but IIRC Intel didn't like the idea > > in > > the end. > > There can be many ways to expose this information in sysfs. Like this > ... > > > [1] https://lkml.org/lkml/2020/10/2/1208 > > ... exposes /sys/devices/system/cpu/types which, in hybrid parts, > creates a > subdirectory for each type of CPU. Each subdirectory contains a CPU > list > and a CPU map that user space can query. > > The other way is to expose the CPU-type in a file: > > /sys/devices/system/cpu/cpuN/type > > that could return the CPU-type of the CPU N. Is there a preference? But you still have to look at frequency or caches as there are Low power E-cores which will have same type but different capabilities. Thanks, Srinivas
Le 19/06/2024 à 03:53, Pawan Gupta a écrit : > On Tue, Jun 18, 2024 at 02:49:10PM +0200, Brice Goglin wrote: >> Le 17/06/2024 à 11:11, Pawan Gupta a écrit : >>> Hi, >>> >>> This series adds support for CPU-type (CPUID.1A.EAX[31-24] on Intel) to >>> differentiate between hybrid variants P+E, P-only, E-only that share the >>> same Family/Model/Stepping. One of the use case for CPU-type is the >>> affected CPU table for CPU vulnerabilities, which can now use the CPU-type >>> to filter the unaffected variants. >>> >>> * Patch 1 adds cpu-type to CPU topology structure and introduces >>> topology_cpu_type() to get the CPU-type. >>> >>> * Patch 2-4 replaces usages of get_this_hybrid_cpu_type() with >>> topology_cpu_type(). >>> >>> * Patch 5-7 Updates CPU-matching infrastructure to use CPU-type. >>> >>> * Patch 8 cleans up the affected CPU list. >>> >>> * Patch 9 uses the CPU-type to exclude P-only parts from the RFDS affected >>> list. >> >> Hello >> >> Is there still a plan to expose this info in sysfs? > Sure, if it helps userspace. > >> Userspace currently uses frequencies to guess which cores are E or P. >> Intel sent some patches several years ago [1], but they got abandoned >> nowhere as far as I know. There was also some discussion about using a >> "capacity" field like ARM does, but IIRC Intel didn't like the idea in >> the end. > There can be many ways to expose this information in sysfs. Like this ... > >> [1] https://lkml.org/lkml/2020/10/2/1208 > ... exposes /sys/devices/system/cpu/types which, in hybrid parts, creates a > subdirectory for each type of CPU. Each subdirectory contains a CPU list > and a CPU map that user space can query. > > The other way is to expose the CPU-type in a file: > > /sys/devices/system/cpu/cpuN/type > > that could return the CPU-type of the CPU N. Is there a preference? I'd vote for the former. Brice
Le 19/06/2024 à 12:34, srinivas pandruvada a écrit : > On Tue, 2024-06-18 at 18:53 -0700, Pawan Gupta wrote: >> On Tue, Jun 18, 2024 at 02:49:10PM +0200, Brice Goglin wrote: >>> Le 17/06/2024 à 11:11, Pawan Gupta a écrit : >>>> Hi, >>>> >>>> This series adds support for CPU-type (CPUID.1A.EAX[31-24] on >>>> Intel) to >>>> differentiate between hybrid variants P+E, P-only, E-only that >>>> share the >>>> same Family/Model/Stepping. One of the use case for CPU-type is >>>> the >>>> affected CPU table for CPU vulnerabilities, which can now use the >>>> CPU-type >>>> to filter the unaffected variants. >>>> >>>> * Patch 1 adds cpu-type to CPU topology structure and introduces >>>> topology_cpu_type() to get the CPU-type. >>>> >>>> * Patch 2-4 replaces usages of get_this_hybrid_cpu_type() with >>>> topology_cpu_type(). >>>> >>>> * Patch 5-7 Updates CPU-matching infrastructure to use CPU-type. >>>> >>>> * Patch 8 cleans up the affected CPU list. >>>> >>>> * Patch 9 uses the CPU-type to exclude P-only parts from the RFDS >>>> affected >>>> list. >>> >>> Hello >>> >>> Is there still a plan to expose this info in sysfs? >> Sure, if it helps userspace. >> >>> Userspace currently uses frequencies to guess which cores are E or >>> P. >>> Intel sent some patches several years ago [1], but they got >>> abandoned >>> nowhere as far as I know. There was also some discussion about >>> using a >>> "capacity" field like ARM does, but IIRC Intel didn't like the idea >>> in >>> the end. >> There can be many ways to expose this information in sysfs. Like this >> ... >> >>> [1] https://lkml.org/lkml/2020/10/2/1208 >> ... exposes /sys/devices/system/cpu/types which, in hybrid parts, >> creates a >> subdirectory for each type of CPU. Each subdirectory contains a CPU >> list >> and a CPU map that user space can query. >> >> The other way is to expose the CPU-type in a file: >> >> /sys/devices/system/cpu/cpuN/type >> >> that could return the CPU-type of the CPU N. Is there a preference? > But you still have to look at frequency or caches as there are Low > power E-cores which will have same type but different capabilities. Good point. From this patch series, I understand that the current kernel side doesn't care about these different E-cores. However it might be good to expose them as different cpu-types (or better name) to userspace ? Something like type 0 = P-core, 1 = normal E-core, 2 = low power E-core ? Brice
On 6/19/24 14:25, Brice Goglin wrote: > Good point. From this patch series, I understand that the current kernel > side doesn't care about these different E-cores. However it might be > good to expose them as different cpu-types (or better name) to userspace ? > > Something like type 0 = P-core, 1 = normal E-core, 2 = low power E-core ? The first priority here is getting the kernel to comprehend these types for architectural purposes: when there are functional differences between the cores. Let's get that in place, first. Then we can discuss the possibility of new ABI in the area. Did the ARM folks ever do a sysfs ABI for big.LITTLE? I don't see anything obvious in Documentation/ABI/testing/sysfs-devices-system-cpu.
Le 20/06/2024 à 17:06, Dave Hansen a écrit : > On 6/19/24 14:25, Brice Goglin wrote: >> Good point. From this patch series, I understand that the current kernel >> side doesn't care about these different E-cores. However it might be >> good to expose them as different cpu-types (or better name) to userspace ? >> >> Something like type 0 = P-core, 1 = normal E-core, 2 = low power E-core ? > The first priority here is getting the kernel to comprehend these types > for architectural purposes: when there are functional differences > between the cores. > > Let's get that in place, first. Then we can discuss the possibility of > new ABI in the area. Agreed. > Did the ARM folks ever do a sysfs ABI for big.LITTLE? I don't see > anything obvious in Documentation/ABI/testing/sysfs-devices-system-cpu. As far as I know, they only have the "capacity" field in sysfs cpu files that reports a higher number for the equivalent of P-core: From testing/sysfs-devices-system-cpu: What: /sys/devices/system/cpu/cpuX/cpu_capacity Date: December 2016 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> Description: information about CPUs heterogeneity. cpu_capacity: capacity of cpuX. I don't know how it's calculated but I've never seen it report something wrong. On Android/ARM phones, big cores usually have 1024 and small cores something between 400 and 500. Where there are 3 types of cores, they report 1024, 500-800 about ~250. Brice
On Thu, Jun 20, 2024 at 05:22:59PM +0200, Brice Goglin wrote: > Le 20/06/2024 à 17:06, Dave Hansen a écrit : > > > On 6/19/24 14:25, Brice Goglin wrote: > > > Good point. From this patch series, I understand that the current kernel > > > side doesn't care about these different E-cores. However it might be > > > good to expose them as different cpu-types (or better name) to userspace ? > > > > > > Something like type 0 = P-core, 1 = normal E-core, 2 = low power E-core ? > > The first priority here is getting the kernel to comprehend these types > > for architectural purposes: when there are functional differences > > between the cores. > > > > Let's get that in place, first. Then we can discuss the possibility of > > new ABI in the area. > > Agreed. Sorry replying late, I was on vacation. Yes, let's leave the ABI for another series when we have a clear use case.
On Thu, Jun 20, 2024 at 08:06:11AM -0700, Dave Hansen wrote: > On 6/19/24 14:25, Brice Goglin wrote: > > Good point. From this patch series, I understand that the current kernel > > side doesn't care about these different E-cores. However it might be > > good to expose them as different cpu-types (or better name) to userspace ? > > > > Something like type 0 = P-core, 1 = normal E-core, 2 = low power E-core ? > > The first priority here is getting the kernel to comprehend these types > for architectural purposes: when there are functional differences > between the cores. > > Let's get that in place, first. Then we can discuss the possibility of > new ABI in the area. > > Did the ARM folks ever do a sysfs ABI for big.LITTLE? I don't see > anything obvious in Documentation/ABI/testing/sysfs-devices-system-cpu. > ARM has the interface /sys/devices/system/cpu/cpu0/regs/identification Here they show the Main ID Register [A]. This register has CPU identification fields such as architecture and other details. The architecture can be specified as a number or refer to architecture-specific features in other registers. On my DragonBoard 845c, this interface shows different values for different types of CPUs. For functionality, there is also a /sys/devices/system/cpu/aarch32_el0. It lists the CPUs that can 32-bit ARM programs on processors in which only a subset of CPUs can do it. ARM gives userspace specific details. This makes more sense to me. Instead of reading these details, user space would have to infer these details if a CPU type was given in sysfs. Having said that, Intel does have a CPUID leaf that gives the CPU type. Such leaf also has a "Native Model ID". Exposing only the CPU type may not be sufficient. [A]. https://developer.arm.com/documentation/ddi0595/2020-12/AArch64-Registers/MIDR-EL1--Main-ID-Register
On Wed, Jun 19, 2024 at 03:34:46AM -0700, srinivas pandruvada wrote: [...] > > > > There can be many ways to expose this information in sysfs. Like this > > ... > > > > > [1] https://lkml.org/lkml/2020/10/2/1208 > > > > ... exposes /sys/devices/system/cpu/types which, in hybrid parts, > > creates a > > subdirectory for each type of CPU. Each subdirectory contains a CPU > > list > > and a CPU map that user space can query. > > > > The other way is to expose the CPU-type in a file: > > > > /sys/devices/system/cpu/cpuN/type > > > > that could return the CPU-type of the CPU N. Is there a preference? > > But you still have to look at frequency or caches as there are Low > power E-cores which will have same type but different capabilities. By the way, /sys/devices/system/cpuN/cache is broken on these systems with low power Ecores. I proposed a patch to fix it here [B]. May I ask for a few extra reviews and testing? Perhaps this will raise the confidence of the x86 maintainers? :) The patchset continues to apply cleanly on v6.10-rc5. [B]. https://lore.kernel.org/all/20231212222519.12834-5-ricardo.neri-calderon@linux.intel.com/
On Thu, Jun 20, 2024 at 05:22:59PM +0200, Brice Goglin wrote: > Le 20/06/2024 à 17:06, Dave Hansen a écrit : > > > On 6/19/24 14:25, Brice Goglin wrote: > > > Good point. From this patch series, I understand that the current kernel > > > side doesn't care about these different E-cores. However it might be > > > good to expose them as different cpu-types (or better name) to userspace ? > > > > > > Something like type 0 = P-core, 1 = normal E-core, 2 = low power E-core ? > > The first priority here is getting the kernel to comprehend these types > > for architectural purposes: when there are functional differences > > between the cores. > > > > Let's get that in place, first. Then we can discuss the possibility of > > new ABI in the area. > > Agreed. > > > Did the ARM folks ever do a sysfs ABI for big.LITTLE? I don't see > > anything obvious in Documentation/ABI/testing/sysfs-devices-system-cpu. > > As far as I know, they only have the "capacity" field in sysfs cpu files > that reports a higher number for the equivalent of P-core: > > From testing/sysfs-devices-system-cpu: > > What: /sys/devices/system/cpu/cpuX/cpu_capacity > Date: December 2016 > Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> > Description: information about CPUs heterogeneity. > > cpu_capacity: capacity of cpuX. > > I don't know how it's calculated but I've never seen it report something wrong. > On Android/ARM phones, big cores usually have 1024 and small cores something > between 400 and 500. > Where there are 3 types of cores, they report 1024, 500-800 about ~250. I *think* this information comes from firmware tables, but you cannot reliably infer CPU types from capacity (e.g., Intel's Ecores vs Low Power Ecores). Also, it is not useful to identify "performance" vs "efficient" CPUs.
On Thu, Jun 27, 2024 at 05:51:54AM -0700, Ricardo Neri wrote: > ARM gives userspace specific details. This makes more sense to me. Instead > of reading these details, user space would have to infer these details if > a CPU type was given in sysfs. > > Having said that, Intel does have a CPUID leaf that gives the CPU type. Such > leaf also has a "Native Model ID". Exposing only the CPU type may not be > sufficient. Do we know if there are applications that would benefit from this information? We agreed to leave sysfs for another series. I will be sending v2 soon.
On Wed, Jun 19, 2024 at 11:22:16PM +0200, Brice Goglin wrote: [...] > > There can be many ways to expose this information in sysfs. Like this ... > > > > > [1] https://lkml.org/lkml/2020/10/2/1208 > > ... exposes /sys/devices/system/cpu/types which, in hybrid parts, creates a > > subdirectory for each type of CPU. Each subdirectory contains a CPU list > > and a CPU map that user space can query. > > > > The other way is to expose the CPU-type in a file: > > > > /sys/devices/system/cpu/cpuN/type > > > > that could return the CPU-type of the CPU N. Is there a preference? > > > I'd vote for the former. +1. With the former you can read all CPUs of a given type in one go whereas with the latter you have to iterate over all CPUs. By the time you are done CPUs may have gone offline or online.
On Tue, Jun 18, 2024 at 02:49:10PM +0200, Brice Goglin wrote: > Le 17/06/2024 à 11:11, Pawan Gupta a écrit : [...] > Hello > > Is there still a plan to expose this info in sysfs? Userspace currently uses > frequencies to guess which cores are E or P. Intel sent some patches several > years ago [1], but they got abandoned nowhere as far as I know. At the time of writing those patches an alternative interface emerged from perf sysfs. You can read the CPUs of a given type from /sys/devices/cpu_{core,atom}/cpus . Yes, this is perf sysfs, but is not obvious from the name and has a list of CPUs. It meet the need, IMO.
On Thu, Jun 27, 2024 at 06:22:30AM -0700, Pawan Gupta wrote: > On Thu, Jun 27, 2024 at 05:51:54AM -0700, Ricardo Neri wrote: > > ARM gives userspace specific details. This makes more sense to me. Instead > > of reading these details, user space would have to infer these details if > > a CPU type was given in sysfs. > > > > Having said that, Intel does have a CPUID leaf that gives the CPU type. Such > > leaf also has a "Native Model ID". Exposing only the CPU type may not be > > sufficient. > > Do we know if there are applications that would benefit from this information? Probably not, but exposing it would follow ARM's approach of exposing the raw details and let user space consume it as it wishes instead of having kernel give an answer that could probably be imcomplete. > > We agreed to leave sysfs for another series. I will be sending v2 soon. It is fine, just wanted to express some opinions. :)
On 2024-06-27 9:22 a.m., Pawan Gupta wrote: > On Thu, Jun 27, 2024 at 05:51:54AM -0700, Ricardo Neri wrote: >> ARM gives userspace specific details. This makes more sense to me. Instead >> of reading these details, user space would have to infer these details if >> a CPU type was given in sysfs. >> >> Having said that, Intel does have a CPUID leaf that gives the CPU type. Such >> leaf also has a "Native Model ID". Exposing only the CPU type may not be >> sufficient. > > Do we know if there are applications that would benefit from this information? > Perf should needs it in the kernel to distinguish between different type of e-cores on ARL-H. +Dapeng, who is working on ARL-H PMU enabling. Thanks, Kan
Le 27/06/2024 à 15:22, Pawan Gupta a écrit : > On Thu, Jun 27, 2024 at 05:51:54AM -0700, Ricardo Neri wrote: >> ARM gives userspace specific details. This makes more sense to me. Instead >> of reading these details, user space would have to infer these details if >> a CPU type was given in sysfs. >> >> Having said that, Intel does have a CPUID leaf that gives the CPU type. Such >> leaf also has a "Native Model ID". Exposing only the CPU type may not be >> sufficient. > Do we know if there are applications that would benefit from this information? There are HPC users who want a homogeneous set of cores, ie only P-core, or only E-core without the low power ones (because they don't want some imbalance between task speed in homogeneous parallel jobs). I've received requests from hwloc users running small parallel jobs on their desktop/laptop machines, and also from developers of big apps who want to debug on their laptop without heterogeneous cores creating imbalance that don't exist on servers. They don't care much about the actual hardware details so far, they mostly want an ordered list of set of homogeneous cores (ordered from performance -> low-energy). Brice
Hi, This series adds support for CPU-type (CPUID.1A.EAX[31-24] on Intel) to differentiate between hybrid variants P+E, P-only, E-only that share the same Family/Model/Stepping. One of the use case for CPU-type is the affected CPU table for CPU vulnerabilities, which can now use the CPU-type to filter the unaffected variants. * Patch 1 adds cpu-type to CPU topology structure and introduces topology_cpu_type() to get the CPU-type. * Patch 2-4 replaces usages of get_this_hybrid_cpu_type() with topology_cpu_type(). * Patch 5-7 Updates CPU-matching infrastructure to use CPU-type. * Patch 8 cleans up the affected CPU list. * Patch 9 uses the CPU-type to exclude P-only parts from the RFDS affected list. Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> --- Pawan Gupta (9): x86/cpu/topology: Add x86_cpu_type to struct cpuinfo_topology cpufreq: intel_pstate: Use topology_cpu_type() to get cpu-type perf/x86/intel: Use topology_cpu_type() to get cpu-type x86/cpu: Remove get_this_hybrid_cpu_type() x86/cpu: Name CPU matching macro more generically (and shorten) x86/cpu: Add cpu_type to struct x86_cpu_id x86/cpu: Update x86_match_cpu() to also use cpu-type x86/bugs: Declutter vulnerable CPU list x86/rfds: Exclude P-only parts from the RFDS affected list .../admin-guide/hw-vuln/reg-file-data-sampling.rst | 8 -- arch/x86/events/intel/core.c | 2 +- arch/x86/include/asm/cpu.h | 6 - arch/x86/include/asm/cpu_device_id.h | 117 +++++++----------- arch/x86/include/asm/processor.h | 3 + arch/x86/include/asm/topology.h | 9 ++ arch/x86/kernel/cpu/common.c | 136 +++++++++++---------- arch/x86/kernel/cpu/debugfs.c | 1 + arch/x86/kernel/cpu/intel.c | 16 --- arch/x86/kernel/cpu/match.c | 22 ++++ arch/x86/kernel/cpu/topology_common.c | 9 ++ drivers/cpufreq/intel_pstate.c | 14 +-- include/linux/mod_devicetable.h | 2 + 13 files changed, 166 insertions(+), 179 deletions(-) --- base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670 change-id: 20240617-add-cpu-type-4d5e47efc117 Best regards,