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.
Created attachment 189171 [details] Patch to fix the broken functionality Patch to fix the broken functionality. Tested on Gentoo Linux (software specs in bug report). Cores will be named as originally intended; ie: "CPU 1 Core 1" through to "CPU X Core Y" where X is the number of CPUs in the system (highest observed "physical id" in /proc/cpuinfo) and Y is however many cores have been observed belonging to that particular physical id.
Thank you for providing a patch to fix the issue with the bug report! However we dont use bugzilla for patch submission review, if you want please submit it as a MR at https://invent.kde.org/plasma/ksystemstats. Thanks again!
(In reply to David Redondo from comment #2) > Thank you for providing a patch to fix the issue with the bug report! > However we dont use bugzilla for patch submission review, if you want please > submit it as a MR at https://invent.kde.org/plasma/ksystemstats. Thanks > again! Sorry about that, it's been a while since I've tried contributing to any sort of an open source project. I've created a merge request as requested: https://invent.kde.org/plasma/ksystemstats/-/merge_requests/124 Thank you for your time! -KT
Git commit 50c48d1cea7a1812a92577af0e9f1d0c424b51ee by Arjen Hiemstra, on behalf of Keven Tipping. Committed on 25/03/2026 at 13:47. Pushed by ahiemstra into branch 'master'. Fix core naming scheme in linuxcpuplugin.cpp This attempts to fix the way CPU core names are generated on systems with more than one physical CPU ("physical id" \> 0 in /proc/cpuinfo). The previous code would often result in negative core indices due to the way it subtracted an accumulated processor sibling count from the current processor ID. I believe the original code assumed that all cores that belonged to a specific physical ID would be listed contiguously in /proc/cpuinfo; however this is often not the case (it varies largely based on the layout of the underlying hardware). On my Z10PA-D8 based system, for example, the /proc/cpuinfo core layout is roughly as follows: * processor 0, physical core 0 to 13 * processor 1, physical core 14 to 27 * processor 0, virtual (HT) core 28 to 41 * processor 1, virtual (HT) core 42 to 55 When the physical ID changed (info.cpu in this case), previousCpuSiblings would get incremented by the current core's sibling count (which is 28 my E5-2690v4 chips). This would result in the CPU indices getting pushed into the negative after the first 13 cores, resulting in some wonky core naming in applications like System Monitor. This patch attempts to fix that by keeping track of the current core on a per-processor basis instead. A simple QVector is used to keep track of the current core index for any given physical ID and bumped for every core encountered. This results in the expected CPU naming scheme (ie, "CPU 1 Core 1" through to "CPU 1 Core 28"). Technically this doesn't handle holes that might occur from offline processors, but figuring that out from /proc/cpuinfo alone is not very trivial with multiple chips and it's just a minor aesthetic issue in the end. M +6 -0 plugins/cpu/autotests/TestLinuxCpu.cpp A +1567 -0 plugins/cpu/autotests/fixtures/linux_amd64_numa_cpuinfo.txt A +2 -0 plugins/cpu/autotests/fixtures/linux_amd64_numa_cpuinfo.txt.license M +12 -7 plugins/cpu/linuxcpuplugin.cpp https://invent.kde.org/plasma/ksystemstats/-/commit/50c48d1cea7a1812a92577af0e9f1d0c424b51ee