https://bugs.kde.org/show_bug.cgi?id=515435
Bug ID: 515435
Summary: CPU core names are incorrect on systems with more than
one physical CPU
Classification: Frameworks and Libraries
Product: ksystemstats
Version First 6.5.5
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: General
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
Created attachment 189170
--> https://bugs.kde.org/attachment.cgi?id=189170&action=edit
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.
--
You are receiving this mail because:
You are watching all bug changes.
