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

Raymond

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%.

20 comments

Comments are closed. Login to edit/delete your existing comments

  • Brian Boorman

    The only correct answer is to hire Dave Plummer back on a contract assignment to update Task Manager to show “Current CPU Performance” (or some other appropriate name) that displays the current CPU voltage/frequency performance as a percentage of maximum performance. Or add a line to the CPU graph showing current CPU throttling versus load like the first graph in your article.

    • Alex Martin

      And while he’s working on that he might as well change some window class names…

  • 紅樓鍮

    So a negatively throttled (e. g. overclocked, Turbo Boost™ed) CPU will report 100% utilization and still have unused time slices?

    • Oleg Mikhailov

      Good point. There is no strict frequency limit for modern CPUs and this makes second approach simply impossible to implement, so, there is nothing to discuss.

    • Henrich Horvath

      Maybe throttling as Raymond explains it, seems to be “putting Noop after every instruction” making CPU 50% speed on the same frequency. So overclocking is not “negative throttling” here.

  • Valts Sondors

    What about other reasons why a CPU might not be performing optimally? Say, you’re running a memory-intensive program which processes a lot of data that is in the RAM. I dunno, video encoding maybe? The point being – the CPU spends a lot of its time stalled, waiting for data to arrive from RAM (or maybe synchronizing between cores). It’s not doing useful work, but it’s also not available for other tasks. Should this count as 100% busy?

    • Raymond ChenMicrosoft employee

      While the CPU is stalled, other hyperthreaded processors on the same core can run, so the CPU capability is still available. If all hyperthreaded processors are stalled, then the CPU cannot do anything, so it is at 100% capacity, even though it also isn’t making progress.

  • Piotr Siódmak

    Depends on what question is the user asking.

    Who started using up more CPU about 5 seconds ago when the fan stated going vrooooom? – The per-process CPU usage graph should not change relative to Max CPU.
    How is the system handling my CPU usage? Did the web browser started being choppy 5 seconds ago because the system started throttling or is it because someone suddenly hogged the whole CPU? – again not relative to Max CPU, with the Max CPU as a separate graph to see if it changed.

    Those are historical values – you look at a set of data over time.

    There is also the immediate value. This one should be relative to Max CPU, because it answers the question “Who is using the most of my CPU” and “How much CPU do I have available”, or rather “Are things slow, because I ran out of CPU”. This one is not graphed.

    What other questions could a user ask when looking at CPU usage?

  • Letao Wang

    Doesn’t this depend on what colored glasses you’re wearing?
    With CPU-colored glasses, you’d want to know things like are there free CPU cycles available to run other threads, who is responsible for using up available CPU cycles, etc. In that context, reporting in terms of currently available cycles gives an intuitive answer.
    With program-colored glasses, what you said in the article is true, and reporting in terms of maximum potential cycles gives an intuitive answer.

  • IS4

    I think it depends on what kind of throttling we are talking about. When I decrease the power consumption of the CPU in the Windows settings, it obviously decreases its speed, but the CPU usage of all processes as reported is unaffected, since all processes are equally affected. However, if this did something else, like setting the minimal value for idle time, thus affecting only processes over the limit, you’d probably want all the usages plus idle to sum up to 100 %.

  • Mike Morrison

    “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,’ “. Who looks at task manager, sees a process using 50% CPU, and thinks “nah, that’s not the reason for the slow performance”? Sure, the process may be using 50% CPU for a reason, but still, if the system is running slowly, then such a process would be a prime candidate for an investigation.

  • Erik Johnson

    If displaying “usage relative to 100% CPU” is misleading in one way, and displaying “usage relative to current CPU capability” is misleading in a different way, then we obviously are looking at the problem in the wrong way. It’s not a data problem, it’s a presentation problem.

    In my NSH opinion, the correct way to reflect this is to keep all usages relative to 100% and to create a pseudo-task in the display that is assigned all CPU resources that have been removed from availability. That would mean that the display in your example would show 50% usage by “Thermal CPU Throttling” and 35% by “Active Task” for a displayed total of 85%, which reflects the reality that only 15% of the CPU is available for use. Shading the “Throttling” pseudo-task differently would make this clearer, but is not required.

    If one doesn’t want to use a pseudo-task, then the current graph in Resource Manager implied a different way. It displays available CPU as a blue line overlaying the graph; if this was filled in above as “unavailable” or “throttled” or whatever, in the same visual style that fills below the green line as the total of active tasks, then the display would be intuitively correct – the non-filled area is available and the filled area is not.

    Either way, the task usage display can remain a simple reflection of core time allocated, while the user can correctly attribute behavior between user tasks, the thermal support of their system, or other background tasks or system services.

    • Chris Iverson

      The problem with this method is the reverse possibility – CPUs being boosted. There are many CPUs now that have a rated standard clock speed, and will throttle below that in times of overheat or simply low usage, but they will also boost above that clock speed when the CPU is being heavily utilized.

      How do you display that? Does the “Throttling” show negative percentages? Or does the CPU running at standard clock ALWAYS show as being throttled?