Add option for hyperthread visibility in CPU meter labels by tjk213 · Pull Request #1902 · htop-dev/htop

tjk213 · 2026-02-16T02:14:52Z

This PR adds a show_smt_cpu_labels setting which, when enabled, labels cpu meters with a X{a,b,c,d} convention where X is the physical core ID and a/b/c/d indicates which hyperthread on the core the labeled meter is watching. For example, 8 cores with SMT-2 renders as follows:

   0a[|              ]  4a[|              ]  0b[               ]  4b[               ]
   1a[               ]  5a[|              ]  1b[               ]  5b[|              ]
   2a[               ]  6a[               ]  2b[               ]  6b[||             ]
   3a[               ]  7a[||             ]  3b[               ]  7b[               ]

The setting is off by default and currently only implemented for Linux.

Explorer09 · 2026-02-16T05:37:06Z

I have a concern about using the abbreviation "SMT" as I don't know what it refers to. Maybe you could just say "label CPU by physical cores".

Your idea should be about grouping CPU meter numbers by their physical cores, right? Whether the threads would be labelled as a, b, c, etc. is second.

natoscott · 2026-02-16T07:09:53Z

SMT is a well-known acronym in industry, its perfectly fine to use here - it's short and precise, people who might use this feature know what it means.

Looking at the linked wikipedia page also suggests it is a good term to use too - there's clearly only one possible meaning listed there that could be relevant in the context of htop.

Explorer09 · 2026-02-16T08:29:08Z

SMT is a well-known acronym in industry, its perfectly fine to use here - it's short and precise, people who might use this feature know what it means.

Looking at the linked wikipedia page also suggests it is a good term to use too - there's clearly only one possible meaning listed there that could be relevant in the context of htop.

I would just say "multithread" or "hyperthread" rather than throw in an industry acronym that users need to look up for what it means.

The users of htop could be very new to computers and if we have to explain an acronym in the UI, it fails at being user-friendly.

Note that in the linked Wikipedia page SMT could also refer to surface-mount technology (although I've heard of SMD being used more often than SMT in that context). At first glance I was confused with "smt" being an ugly shorthand for "smart", but anyway I would vote for spelling out the word "multithread" (or "multithreading").

tjk213 · 2026-02-16T14:48:50Z

I would agree that SMT is a standard term & that there is really only one possible fit on that wiki page. With that said, happy to rename the flag if there is consensus on a better name.

Note that the description in the UI uses the term HyperThreads as well, for users who find that more familiar:
Show SMT/HyperThread siblings (e.g. 0a, 0b) instead of CPU number

BenBE

I would agree that SMT is a standard term & that there is really only one possible fit on that wiki page. With that said, happy to rename the flag if there is consensus on a better name.

You can keep SMT. No need for using Intel's proprietary name. Also multithreading can be mistaken for running multiple threads (LWP) of a process, thus also something you'd better avoid.

Note that the description in the UI uses the term HyperThreads as well, for users who find that more familiar: Show SMT/HyperThread siblings (e.g. 0a, 0b) instead of CPU number

I'd suggest to hint to the CPU topology in addition to SMT, which should make the intent of this setting more obvious even to people who don't know what SMT is.

dragonflybsd/DragonFlyBSDMachine.c

linux/LinuxMachine.c

netbsd/NetBSDMachine.c

BenBE · 2026-02-16T19:36:00Z

CPUMeter.c

+         char threadLetter = 'a' + (char)threadIndex;
+         xSnprintf(caption, sizeof(caption), "%2d%c", coreID, threadLetter);


Properly handle more than 26 threads per core …

I know this is rare, but … ;-)

Settings.c

DisplayOptionsPanel.c

Explorer09 · 2026-02-17T02:45:13Z

I would agree that SMT is a standard term & that there is really only one possible fit on that wiki page. With that said, happy to rename the flag if there is consensus on a better name.

You can keep SMT. No need for using Intel's proprietary name. Also multithreading can be mistaken for running multiple threads (LWP) of a process, thus also something you'd better avoid.

When I googled the term "SMT", the first few results I got was pages about surface mount technology. It suggested me that the "SMT" is not that universally used as you would think.

Also, I don't think user would confuse CPU threads with process threads. Those are different things.

As I said, I don't like throwing in a new term without explanation. Even "CPU thread" is better term than "SMT" for the UI (user interface) here. Since you are bothered to spell out the word "Hyperthreads", then "CPU threads" could be a shorter term for conveying the same thing.

EDIT: Read this comment for my updated opinion. I no longer object the term SMT but I would like clarification through surrounding text.

tjk213 · 2026-02-17T05:45:47Z

CPUMeter.c

+      if (host->settings->showCPUSMTLabels) {
+         int coreID = Machine_getCPUPhysicalCoreID(host, cpu - 1);
+         int threadIndex = Machine_getCPUThreadIndex(host, cpu - 1);
+         char threadLetter = 'a' + (char)(threadIndex % 26);


@BenBE I added a wrap so any systems with more than 26 threads per core will just start reusing letters. does that work for you, or would you prefer something else?

Most I've ever heard of is 8 per core, so this seems a sensible approach. Consider adding an assert() so that some hapless developer someday will hit this if ever that limit is reached.

If we distinguish letter cases (a-z and A-Z) then the number of addressable threads can be bumped up to 52. However, I am not sure what's the use case. Since we took a character in the CPU meter label to number the thread, then the maxinum addtressable physical cores went down to 99, and that's another limit worth concerning (and discussion).

EDIT: By the way, would there be users who prefer labeling the cores by letters and threads by numbers?

While wrapping around (and throwing an assert) mitigates the immediate problem, I think a proper fallback like %d:%d might be a more sustainable way to go.

Two options available: Use single letter for first like 26 (or 16) threads, numbers for anything above, or always use numbers if there's some core with more than 26 (or 16) threads. Doing the latter is more complexity to implement, but gives a cleaner UI/UX.

@BenBE There are only three characters of space for a label in a meter, so the thread numbering has to constrain to one or two characters. The extra character like a colon : is not an option.

I think a much easier, temporary solution is to mark threads greater than 26 as * instead of a letter. Yes, that would create duplicate labels, but as long as the threads are grouped together, I don't see that would create a big problem.

I am against repeating letters, by the way. Imagine when you communicate with someone and point out that threads "16a" to "16d" are always 100% busy, and your friend asks you which "16a" thread you are referring to.

An asterisk would be better if we run out of letters.

Let's use CJK characters in Unicode-enabled versions of htop. That way we don't need to consider multi-character identifier variants until we get to well above 100k threads …

Hey, core 42炎 is in flames!

/jk

Okay, back to the serious side of things: Priority should be on making things distinguishable. That's an issue that we already face with systems with more than 999 cores (which exist in data centers). So regardless of what notation we choose, there will be a limit on how many cores we can uniquely identify.

And to give a point of relevance: On UltraSPARC Niagara systems it is feasible to run htop where it could encounter topologies with 32 or more threads per core. Similarly libvirt/QEMU (KVM) will present you with about anything you ask it to show to a guest. So keeping this in mind when devising a solution for marking the topology is crucial.

Let's use CJK characters in Unicode-enabled versions of htop. That way we don't need to consider multi-character identifier variants until we get to well above 100k threads …

Hey, core 42炎 is in flames!

As a native Chinese speaker I can't understand this joke. Besides, CJK characters occupy two terminal columns per character, and we have only three terminal columns for a meter...

(On the other hand, it is indeed possible to label a thousand CPU cores with two terminal columns of space if you indeed use CJK. The catch is, almost no one memorises the order of those characters.)

Okay, back to the serious side of things: Priority should be on making things distinguishable. That's an issue that we already face with systems with more than 999 cores (which exist in data centers). So regardless of what notation we choose, there will be a limit on how many cores we can uniquely identify.

And to give a point of relevance: On UltraSPARC Niagara systems it is feasible to run htop where it could encounter topologies with 32 or more threads per core. Similarly libvirt/QEMU (KVM) will present you with about anything you ask it to show to a guest. So keeping this in mind when devising a solution for marking the topology is crucial.

Good info for a 32 thread system. But then, what prevents us from using both uppercase and lowercase letters? That way we can label up to 52 threads.

i pushed an update to add capital letters

thanks for the info about sparc & qemu, that's super interesting!

DisplayOptionsPanel.c

BenBE · 2026-02-17T22:57:11Z

@tjk213 Please rebase and squish your commits to show the necessary changes instead of the path taken to get there. Doing like 3 commits (one introducing the setting, one introducing the data collection required, and one implementing the display) fully suffices. No need to spam like 14 commits at this change. ;-)

BenBE requested changes Feb 16, 2026

View reviewed changes

BenBE added the feature request Completely new feature requested label Feb 16, 2026

BenBE added this to the 3.5.0 milestone Feb 16, 2026

tjk213 commented Feb 17, 2026

View reviewed changes

Explorer09 reviewed Feb 17, 2026

View reviewed changes

DisplayOptionsPanel.c Show resolved Hide resolved

tjk213 added 3 commits February 19, 2026 19:25

Add getCPUPhysicalCoreID() and getCPUPhysicalCoreID()

1c6f4e8

Add show_cpu_smt_labels setting

e0ddc87

Implement letter index

cbc1265

tjk213 force-pushed the tyler/smt-labeling branch from d6e3aad to cbc1265 Compare February 20, 2026 00:27

Add capital letters

c64b1de

		char threadLetter = 'a' + (char)threadIndex;
		xSnprintf(caption, sizeof(caption), "%2d%c", coreID, threadLetter);

Uh oh!

Comments

Conversation

tjk213 commented Feb 16, 2026

Uh oh!

Explorer09 commented Feb 16, 2026

Uh oh!

natoscott commented Feb 16, 2026

Uh oh!

Explorer09 commented Feb 16, 2026

Uh oh!

tjk213 commented Feb 16, 2026

Uh oh!

BenBE left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Explorer09 commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Explorer09 Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

BenBE commented Feb 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Explorer09 commented Feb 17, 2026 •

edited

Loading

Explorer09 Feb 17, 2026 •

edited

Loading