On Mon, Jan 15, 2024 at 05:58:18 -0800, Andrea Bolognani wrote:
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?
Ah, sorry, I forgot to respond. I think this explanation makes sense,
and since the HW I've mentioned is now obsolete as well as kernel
markign the fields as deprecated:
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>