[FR] Add meter to show PHYSICAL cores only, not SMT/Hyperthreading cores (x86)

[Heavygrass]

Hi!
It would be nice if there would be a simple to setup meter that would show only physical cores, instead of the (double on Ryzen) SMT/Hyperthreading # of cores.

The number of cores is quickly growing recently, this would significantly reduce the amount of displayed info while preserving most important info.

This meter could average load between SMT virtual cores belonging to the same physical core.
To be specific this is requested here for x86, Linux and a single CPU for simplicity.

Sorry if this is already implemented, my current htop version is 3.3.0.
Thank you.

[BenBE]

In order to group the logical cores together and only show the "physical" cores requires the CPU topology to be processed (for each update of the load information). Currently we try to keep working with the topology information to a minimum, as it produces quite a few edge cases, like multi-CPU systems, where one CPU has SMT, the other does not. Or how to handle things if one core is marked as offline, while the other is working. Just to name a few kinda obvious cases, where simply grouping and calling it done doesn't quite cut it.

Another issue is regarding fetching the topology information in the first place. AFAIK this is currently implemented on Linux only, as that's the only place where we actually need it (for libsensors¹ to properly place temperature readings for CPU cores).

Thus while I understand the idea, I'm not convinced it is worth the trouble. But a proper PR can absolutely be a good starting ground for an implementation of this idea.

¹Which is TBH a PITA to work with.

[Heavygrass]

Thank you for your response.

like multi-CPU systems, where one CPU has SMT, the other does not

May I ask how many objects/indicators you can follow simultaneously (each one of them at the same time)?
I've read most people can follow up to 7 objects (most people even less).
How many logical cores multi-CPU systems you believe have on average?

requires the CPU topology to be processed (for each update of the load information)

I believe currently the default update interval is 5 sec.
What % you believe of htop users changes CPU topology every 5 seconds?
Why CPU topology update can't be done say once in 10 min?

[BenBE]

Thank you for your response.

like multi-CPU systems, where one CPU has SMT, the other does not

May I ask how many objects/indicators you can follow simultaneously (each one of them at the same time)? I've read most people can follow up to 7 objects (most people even less). How many logical cores multi-CPU systems you believe have on average?

My objection was not regarding the number of objects to follow (if you really wanted to minimize this, you can choose the CPU average meter, which just has one single bar ;-)), the objection was regarding how you want edge cses to be handled. And these can get complicated fast.

requires the CPU topology to be processed (for each update of the load information)

I believe currently the default update interval is 5 sec. What % you believe of htop users changes CPU topology every 5 seconds? Why CPU topology update can't be done say once in 10 min?

And handling the CPU topology is not a matter of update speed (htop parses about 200 million integers from textual data for every update interval (1.5 seconds by default BTW). Thus the problem is again not with the time complexity (which is at most O(n²) if you did processing really inefficiently) with n ~ 1000 for the largest systems currently. Rather the complexity is with the edge cases: Maybe a quick one: Let's take this CPU, you might have come across. Has it a) 1, b) 2, c) 8, or d) 9 cores? Okay, let's assume, it got 2, because you have the PPE and the 8x SPE. Except, the 8th SPE isn't accessible usually due to reasons. ;-) You now have to map your virtual "cores" back to the real cores your system gives you, which is linear in runtime when you pre-processed your CPU topology. But even for this kinda common CPU, deciding the number of cores to display isn't easy. And that's one of the more "conventional" chips out there. And I know it can run Linux … And TBH, Linux runs on chips far stranger than this.

[Heavygrass]

you can choose the CPU average meter, which just has one single bar

Yes, that's what I actually had to do even though I don't have that many cores. I realized that I simply cannot follow so many indicators.
But one does loose quite a bit of important information with one single bar.

the objection was regarding how you want edge cses to be handled

We need to go step by step here. My earlier questions are designed to help determine whether some of edge cases are even relevant for a user.
A new meter could also simply report "not implemented" in edge cases.

Another way could be to allow a user to manually specify which logical cores to average.