htop 3.4.1 shows 800% cpu usage instead of 100% cpu usage

[bs2345000999-png]

While running sha256sum /dev/zero
htop incorrectly show 800% cpu usage instead of 100% cpu usage

using Termux
htop version 3.4.1
downloaded from latest github actions build (htop)

[fasterit]

The normal sha256sum from coreutils is single threaded. So it should only go up to 100% (one of your presumably 8 CPU cores).
Can you make a screenshot?

[oxonomiAK]

That's strange - sha256sum from coreutils is single-threaded, so it shouldn't load more than 100% of a single core.
I checked this on my system using Synd3 (a Linux process manager). Synd3 shows both:

1. "How much the entire processor is being used by each process - so in the case of a single-threaded process on an 6-core/12-thread CPU, it shows around 8-9% CPU load."
2. "Graphs of per-core usage - they show that one core is at 100% but without specifying which process is using it."

This way you can see both the total CPU load and the per-core distribution. For reference, here's a screenshot comparing htop and Synd3:

You can find Synd3 here: https://github.com/oxonomiAK/synd3

[BenBE]

Synd3 uses CPU utilization (thus the 8.3%, which is 100%/12), while htop shows core utilization, hence the 100% (the .6 can be a timing artifact when collecting the data).

Cf. https://youtu.be/W4EwfEU8CGA?t=503, where things are explained quite nicely.

[oxonomiAK]

Thanks for the clarification.
So if I understand correctly, the 100.6% comes from delta-based sampling of /proc/stat and timing granularity between reads, rather than actual overcommit of a core.
Out of curiosity - is the value intentionally left unclamped to reflect raw measurements? Or would clamping to 100% for single-threaded cases make sense from a UI perspective?

[BenBE]

There's no explicit code handling the clamping and given that the overall processing of the data from procfs is a kinda tight loop, you do not want to do too much unnecessary post-processing. htop does some normlization, as data is not strictly sampled each second, but every 1.5 seconds (cf. Setup screen -> Display Uptions -> Update interval). Thus based on jitter and other factors, the scaling to one second might be off slightly, causing these effects.

More details can be found (for Linux) in linux/LinuxProcessTable.c in the functions LinuxProcessTable_readStatFile and LinuxProcessTable_adjustTime.