On Fri, Jan 12, 2024 at 08:58:52AM -0800, Andrea Bolognani wrote: > On Fri, Jan 12, 2024 at 05:18:31PM +0100, Peter Krempa wrote: > > On Thu, Jan 11, 2024 at 15:26:41 +0100, Andrea Bolognani wrote: > > > + Each ``cpu`` element contains the following attributes: > > > + > > > + ``core_id`` > > > + Identifier for the core the CPU is in. > > > + > > > + ``siblings`` > > > + List of CPUs that are in the same core. > > > + > > > + The list will include the current CPU, plus all other CPUs that have the > > > + same values for ``socket_id``, ``die_id`` and ``core_id``. > > > > IIRC the bit about 'core_id' is not true, at least for some older AMD > > cpus which had two fixed point units (each having it's own core id) > > sharing a FPU and some other less-used modules. > > > > That was a long time ago though, but the distinction was that the lowest > > level cache was shared at this level (again IIRC) > > > > See commit 828820e2d371205d6a6061301165d58a1a92e611 ; the 'bulldozer' > > example. > > I've heard the AMD Bulldozer being mentioned as a curiosity several > times over the years. My understanding is that the architecture has > now been completely abandoned, and that the most recent hardware > that employs it was manufactured roughly a decade ago. > > The kernel documentation[1] for the files that we parse to produce > those values is the following: > > What: /sys/devices/system/cpu/cpuX/topology/core_id > Description: the CPU core ID of cpuX. Typically it is the hardware platform's > identifier (rather than the kernel's). The actual value is > architecture and platform dependent. > Values: integer > > What: /sys/devices/system/cpu/cpuX/topology/core_cpus_list > Description: human-readable list of CPUs within the same core. > The format is like 0-3, 8-11, 14,17. > (deprecated name: "thread_siblings_list"). > Values: decimal list. > > So I think that, for all cases that are actually relevant today, the > explanations I'm introducing are accurate. If you have reservations > about them, please let me know how you'd like to change them and we > can certainly find a compromise :) So, can I push this as is with your R-b, or do you want me to make further tweaks? > [1] https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-devices-system-cpu -- Andrea Bolognani / Red Hat / Virtualization _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx