Where does the task manager get CPU utilization numbers?

[TurtlePerson2]

So how does Windows figure out the CPU utilization and what does that even mean? I'm a computer architecture and VLSI design student so I know how a CPU works and I can't figure out how you would ever get to 100% CPU utilization on a consistent basis. It seems that branch mispredicts (as rare as they may be), cache misses, and certain data hazards will prevent you from having all functional units full.

Is the CPU utilization a software monitor and not a hardware monitor? If so, then is it truly accurate?

[notfred]

Disclaimer - I have no knowledge of the Windows internals, but I have looked at CPU usage monitoring in other OS. It's usually just a software monitor, it's a count of when the kernel has a task running on the processor. You are correct in that it's basically impossible to have all the functional units running at the same time, that's why they started quoting TDP (Thermal Design Power) rather than just summing up the power of all the logical blocks.

[accord1999]

I'd imagine it's simply calculated by the amount of time that a process/thread is doing something on the CPU versus the amount of time the CPU is idle. A simple endless loop doing essentially no work will still show 100% utilization in a task manager.

To get accurate utilization of CPU resources, you probably need things like VTune that can query the performance counters off the CPU.

[cphite]

So how does Windows figure out the CPU utilization and what does that even mean? I'm a computer architecture and VLSI design student so I know how a CPU works and I can't figure out how you would ever get to 100% CPU utilization on a consistent basis. It seems that branch mispredicts (as rare as they may be), cache misses, and certain data hazards will prevent you from having all functional units full.

Is the CPU utilization a software monitor and not a hardware monitor? If so, then is it truly accurate?

I believe it is a software monitor. As for accuracy, it's likely that it's an estimate at some level. The intent is to know if you're overtaxing the system, and for that purpose it seems to work okay.

[ekul]

So how does Windows figure out the CPU utilization and what does that even mean? I'm a computer architecture and VLSI design student so I know how a CPU works and I can't figure out how you would ever get to 100% CPU utilization on a consistent basis. It seems that branch mispredicts (as rare as they may be), cache misses, and certain data hazards will prevent you from having all functional units full.

Is the CPU utilization a software monitor and not a hardware monitor? If so, then is it truly accurate?

Task manager (along with any other software process monitor like top, ps, psexplorer etc) is quite simple. It isn't much more than (available time slices used by process / available time slices). It's not designed to be accurate; it's designed to be close without slowing process execution down to a crawl.

Task Manager doesn't know or care about cache misses, pipeline stalls or branch mispredicts. To see what is going on (and not even to the level of detail you are talking about in some cases) you would need to use something like valgrind or maybe DTrace. If you're really interested in watching what is happening in a windows process I'd recommend http://technet.microsoft.com/en-us/sysinternals/bb896653. It's task manager on steroids and while it still doesn't do stuff like you mentioned it's a lot closer. I'd also recommend reading anything by Mark Russinovich since he is the author of process explorer and perhaps the single best authority on windows internals.

[SecretSquirrel]

It's a rough breakdown of what percentage of time a CPU spends doing a particular task. It is most definitely implemented at the OS/Software level, though there are some CPU hardware facilities that make it possible. Every CPU of which I am aware, even little microcontrollers, have to capability to provide some sort of hardware counter. In x86 compatible CPUs this is a free-running tick counter. As the OS enters a running task, it notes the value of that counter, and again when it comes out of that task back into the OS. The difference in these two values is a measure of how much time the CPU spent in the task. Likewise, the difference between ticks when it comes out of one task and goes into another represents the amount of time spent in the kernel. These values are divided by the number of ticks in a second (or some other time measure) to give a percentage of CPU time. The ticks pass by so quickly that the dozens or even hundreds that pass by while doing the time accounting are just lost in nth decimal round offs of the percentages.

--SS

[notfred]

Every CPU of which I am aware, even little microcontrollers, have to capability to provide some sort of hardware counter. In x86 compatible CPUs this is a free-running tick counter. As the OS enters a running task, it notes the value of that counter, and again when it comes out of that task back into the OS.

[Huge aside] If you're thinking of the TSC counter on x86, that tends not to be used as on some processors it doesn't run at constant rate but varies with power state. Usually a timer tick is setup to drive the timesliced nature of a preemptive multi-tasking OS and then a count of slices is used for CPU usage by process.[End aside]

[bcronce]

So how does Windows figure out the CPU utilization and what does that even mean? I'm a computer architecture and VLSI design student so I know how a CPU works and I can't figure out how you would ever get to 100% CPU utilization on a consistent basis. It seems that branch mispredicts (as rare as they may be), cache misses, and certain data hazards will prevent you from having all functional units full.

Is the CPU utilization a software monitor and not a hardware monitor? If so, then is it truly accurate?

I'm not sure how all OSs figure it out, but Win7 can count clock cycles. It knows roughly how many clock cycles happen within a second and knows exactly how many cycles are being consumed by applications.

As for branch mispredicts, cache misses, etc.. Those reduce the efficiency of your clock cycles, but they don't change how many cycles you get per second. It just means it takes more cycles to complete the work in question.

[bcronce]

Every CPU of which I am aware, even little microcontrollers, have to capability to provide some sort of hardware counter. In x86 compatible CPUs this is a free-running tick counter. As the OS enters a running task, it notes the value of that counter, and again when it comes out of that task back into the OS.

[Huge aside] If you're thinking of the TSC counter on x86, that tends not to be used as on some processors it doesn't run at constant rate but varies with power state. Usually a timer tick is setup to drive the timesliced nature of a preemptive multi-tasking OS and then a count of slices is used for CPU usage by process.[End aside]

Win7 counts exactly how many cycles each thread gets. I can't think of another way to figure this out without using that register. Yes, it increments once per cycle and your cycles per second change, but that still doesn't change how many cycles have been consumed in a given time slice, and you know your max cycles/sec so you can still know your effective CPU time.

[just brew it!]

So how does Windows figure out the CPU utilization and what does that even mean? I'm a computer architecture and VLSI design student so I know how a CPU works and I can't figure out how you would ever get to 100% CPU utilization on a consistent basis. It seems that branch mispredicts (as rare as they may be), cache misses, and certain data hazards will prevent you from having all functional units full.

Is the CPU utilization a software monitor and not a hardware monitor? If so, then is it truly accurate?

It isn't a question of whether all functional units are being kept busy. All the CPU usage numbers tell you is whether your cores had a thread/process scheduled to run or not. The OS does not "see" whether the execution units are actually busy; all it sees is whether the core has something scheduled to run on it.