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 :)
[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
