In Linux, the actual metric is simple. The amount of time a "CPU" (what Linux calls an architectural thread of execution) is not in the idle routine, as a propo

In Linux, the actual metric is simple. The amount of time a "CPU" (what Linux calls an architectural thread of execution) is not in the idle routine, as a proportion of the total time elapsed, and average this over all "CPUs" in the system. It's a simple metric, but it can be complicated to relate it to what is going on with execution because the real system is very complicated. The CPU % metric does not take into account execution strength, of the CPU, big vs small, dynamic CPU frequency, or effect that one CPU might have on another (e.g., SMT or shared caches or memory controllers). Further complicating it is that the Linux CPU scheduler is not work-conserving. So you could have at least 100 application threads runnable at any given moment in your workload, but your 64 CPU system might only be hitting 80% CPU busy. Then you get to application and kernel effects of course, locking, blocking, etc. can mean you don't even have as many runnable threads as you might think. Then how all this actually relates to the work and heat the system creates is another matter again. Simple integer execution might only use half the CPU power of a vector heavy workload because you have fewer transistors clocked or switching (or even powered) in the core.