What should the CPU usage be of a fully-loaded CPU that has been throttled?

Raymond Chen

For simplicity, let’s say you have a single-CPU system that supports “dynamic frequency scaling”, a feature that allows software to instruct the CPU to run at a lower speed, commonly known as “CPU throttling”. Assume for this scenario that the CPU has been throttled to half-speed for whatever reason, could be thermal, could be energy efficiency, could be due to workload. Finally, let’s say that there’s a program that is CPU-intensive, calculating the Mandelbrot set or something.

The question is: What percentage CPU usage should performance monitoring tools report?

One theory is that this should report 100% CPU usage, because that CPU-intensive program is causing the CPU to consume all of its available cycles.

Another theory is that this should report 50% CPU usage, because even though that CPU-intensive program is causing the CPU to consume all of its available cycles, it is not consuming all off the cycles that are potentially available.

The argument for the first point of view is that if your system is acting sluggish, or you hear the fan turn on, you want go to a performance monitor tool and see that, “Oh, program X is using 100% CPU, that’s the problem.” If the system had used the second model, you would see that program X is using 50% CPU, and you would say, “Well, that’s not the problem, because there’s still 50% CPU left for other stuff,” unaware that the other 50% of CPU capacity has been turned off due to throttling.

While I sympathize with this point of view, I feel that reporting the CPU usage at 50% is a more accurate representation of the situation.

If the CPU were reported as a percentage of current available resources, then performance monitoring tools would not only have to record the history of the process’s CPU usage, but they would also have to record the history of the system’s throttling behavior, in order to get an accurate assessment of how much CPU the program was using over time.


In the above diagram, the blue line represents the maximum CPU currently available due to throttling, and the red line represents CPU usage as an absolute amount. At the start of the trace, the CPU is running at full power, and the program is using around 65% of that. The program’s CPU usage slowly drops, and when it gets low enough, the CPU is throttled down to 50% of maximum. The program’s CPU usage remains low for the remainder of the scenario, settling at around 35% of maximum CPU, or 70% of relative CPU.

What you expect to see in your CPU usage graph when analyzing the performance of the program is that it starts out using a lot of CPU (65%) and gradually drops to around 35%.

But suppose CPU usage percentage were relative to current CPU throttling. The graph would start out at around 65% like before, since the CPU is not being throttled. The CPU usage would slowly drop, as before, but when the system throttles the CPU down to 50%, the CPU usage graph would spike up, since its 35% usage of maximum CPU is 70% of available CPU. If you weren’t aware of this change in system CPU throttling, it would look like something happened in your program that caused its CPU usage to jump up suddenly, and remain high for the remainder of the scenario, when in fact the program’s CPU usage was low for the remainder of the scenario!


Here’s another way of looking at it: Suppose the program’s CPU usage was capped by something other than throttling. For example, maybe it’s in a job that is capped to 20% CPU. The program is using all the CPU it can, but the system limits it to 20% of the total. Should this be reported as a program running at 100% CPU? It’s using all of the CPU it has available to it, after all.

Related reading: Why your CPU usage is hovering at 50%.