Created attachment 189170 [details]
Screenshot of bad behavior

SUMMARY

The math in makeCpuNames() seems to make several assumptions about the layout of physical and virtual cores in /proc/cpuinfo that isn't necessarily true on systems with more than one CPU socket. This leads to CPU cores being assigned friendly names with negative indices that don't make much sense.

A picture has been attached of this issue, along with a patch that corrects the problem.

STEPS TO REPRODUCE
1. Open System Monitor
2. Click on the History page

OBSERVED RESULT

CPU core names are nonsensical with negative indices all over the place.

EXPECTED RESULT

CPU core names should follow some sort of contiguous naming scheme.

SOFTWARE/OS VERSIONS

Linux/KDE Plasma: Gentoo Linux 2.18
KDE Plasma Version: 6.5.5
KDE Frameworks Version: 6.22.0
Qt Version: 6.10.1

ADDITIONAL INFORMATION

I've written a patch that attempts to rectify this issue by keeping track of the core indices on a per-physical-processor case. This is achieved by using a simple QVector<unsigned int> where each element corresponds to the "physical id" tag of a processor. Every time a new core is encountered that belongs to a specific CPU package, the core count is incremented by one, leading to reasonably predictable and ordered core indices for the display name of a specific processor.

This might not be the most thorough way to handle things since this means that offline CPU cores will simply "vanish" from the core order and any subsequent cores will get bumped up by one index, but since this is only dealing with aesthetic "friendly" names I'm not sure how much that matters. The layout of /proc/cpuinfo is wildly inconsistent between systems with more than one CPU and trying to map the processor ID to a CPU #/Core # can get incredibly complicated incredibly fast once you realize that processor IDs may or may not be contiguous based on whether or not cores are online/offline, core IDs usually aren't contiguous due to firmware implementations, and the order that things are listed as far as physical IDs are concerned is also subject to change based on the underlying hardware. About the only consistent thing that can be relied upon is the processor IDs (which is exactly what makeCpuNames() does if there's only one CPU), so I think for systems with more than one CPU this is probably the easiest and simplest way of handling things for now.