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@xxxxxxxxxx> _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
