[annoyingnoob]

I think we can have more nuance than a choice of 50% or 100%. I fall in the 'Show 100%' camp for sure, showing 50% but not indicating why isn't particularly helpful without knowing the background here. I think a separate indicator for an overall throttling condition would be helpful. Show a 100% usage and a throttle indicator together.

[sundvor]

Agree 100% (he!). The utilisation really needs to show busy as in % of presently available resources, and displaying what those are is a completely different concern.

For Windows, if anything I'd love to see an additional metric, where the app resource usage is presented in % of available cores.

Eg if I have a single thread app (i.e. a game) on let's say a 10 core CPU with SMP disabled, it might report 10% usage. But looking at the core graphs we see one at 100% with the other 9 idling. So the app is really maxed out at its architectural limit - ie 100%. It would be nice to have an additional column representing this - and maybe an idea of the foreground app's available % usage in other reporting (am I cpu limited, or GPU? people have bought Intel over AMD CPUs for this metric even though multi thread workload capacity has been far greater in AMDs).

Taking a step back again, especially for Ryzen CPUs unless manually locked you'll have different per core frequencies - so the article's suggestion becomes an almost impossible mission: A Mandelbrot processor can be split across all threads rather equally for an unthrottled 10 core run say at 4ghz, but a core limited config may be able to run it at 4.5ghz prior to thermal throttling - what is the real max to report in a 10 core run following that then? And on a very cold day, with fans at a higher RPM, the core limited run might hit a higher 4.8ghz - now what? You just can't; reporting on current CPU capability is a separate concern altogether.

[Tempest1981]

> but not indicating why

Agree, you really want 2 indicators, vs 1 confusing hybrid.

[mjevans]

Consider a tweak to how *nix utilities report currently:

* 100% per core's for the factory target speed (what a CPU is sold to run at non-turbo/boost/whatever)

* turbo / boost displays figures above 100% (per core)

* special fake accounting buckets for not just cpu_idle, but also cpu_powersave, cpu_thermal, etc. Any status caused by yielding or reducing the runable time of that core.

* An additional (does this exist already?) counter of executed instructions, in addition to the run time for each task / thread. On multicore systems this should be recorded for each core the thread can run on. Large NUMA systems might disable, or node restrict, this for obvious reasons.

This would give a clear picture of both the utilization of hardware as a whole, as well in the program context.

[buran77]

Determining how much is in use out of what is practically available is relatively easy. But determining what is 100% is still difficult to decide on, CPUs have too many frequency options to decide what the "real" 100% point is. Even picking the base frequency as the reference would be a pain to properly monitor and predict, and to take decisions based on that.

[annoyingnoob]

Its more about determining what throttling means, 100% for conditions. In any case, the tools we are used to using have traditionally showed a percentage scale of usage - seems like a reasonable measure even if its hard to measure.

[VortexDream]

I fall in the 50% camp because showing 100% when it's clearly not using 100% of what the CPU is capable of is misleading, particularly in troubleshooting performance issues.

[annoyingnoob]

I think either 50% or 100% is misleading without more information. In either case you can be left wondering where your bottleneck might be and your first guess probably is not something like more cooling.

[VortexDream]

I think showing 100% is far worse, because then I have to rely on my subjective experience of the interface I'm working with to notice that something is wrong. 100% isn't just misleading, it's wrong on a UX level. At least when it shows 50%, I immediately have a sense of, "wait, that's wrong" and I can even begin troubleshooting and look at the current clockspeed, temperature, core usage, etc.