For example, a simple program in a simulated environment that waits for user input seems to be doing no work, so I guess it uses CPU only for the time.

I'd like to know if computer systems (that don't have any services installed or are disabled ie. logging, updates, etc) could theoretically have constant/zero/minimum CPU load? (because they would be doing no work)

I don't know if all systems need to have a clock. But even if all systems need to have a clock that needed to count on time, would it be the only service that uses CPU? And would CPU load be constant?

  • 1
    Most computer systems today have a clock outside the CPU, so what makes you think the clock service needs CPU time?
    – Doc Brown
    Feb 19 '17 at 9:37
  • 2
    I don't know anything about hardware. I know too little about operating systems. Feb 19 '17 at 9:38
  • 4
    Just shutdown and poweroff your computer. It would then have a load of 0, but I am not sure it is useful Feb 19 '17 at 19:00
  • 2
    Many microcontrollers have instructions to suspend the CPU until an interrupt or some other event occurs. May 12 '17 at 16:04
  • Re, "a clock that needed to count on time." Are you alluding to the difference between asynchronous logic and synchronous logic? or are you talking about a clock that keeps track of the time-of-day? AFAIK, nobody bases general-purpose computing hardware on asynchronous logic except maybe as an academic exercise. May 12 '17 at 17:39

Could computer systems theoretically have constant/zero/minimum CPU load ?

Of course they can, theoretically. There are three scenarios that I can think of:

Temporary zero CPU load when waiting for an interrupt. (Of course, when the interrupt arrives, there will be some CPU load.) Most computer systems in use today are capable of entering a stop-clock state where the clock is not even ticking, and therefore the power consumed by the CPU is close to zero. Of course, an interrupt will have to arrive at some point, causing the clock to resume and the CPU to start processing it, otherwise the system is useless.

Permanent zero CPU load by disabling interrupts and executing a HALT instruction. Of course, such a system is permanently frozen and of about as much use as a paper weight.

Permanent/tempoary constant CPU load at 100%: Fire as many threads as cores, and have each thread enter a very tight loop. If nothing else is going on in the machine, then the machine will be in constant 100% CPU utilization.

  • So much fun turning off the computer ;-)
    – 5gon12eder
    Feb 20 '17 at 23:43
  • You kids are too young to remember when most operating systems would run the CPU at 100% 100% of the time. Back in the day, most CPUs did not even have a wait-for-interrupt instruction, or if they did, the programmers had not yet figured out the advantage of it. When no other task was runnable, the OS scheduler would switch to the "idle task", which literally could be as simple as while(true); It wasn't until maybe the 1980s or so when computers were no longer kept in their own air-conditioned vaults, that developers started to worry about power consumption and heat output. May 12 '17 at 17:28
  • @jameslarge don't be fooled by my avatar picture, which is from my youth. But answers posted today must be expressed in terms applicable to today. Plus, I am in the relatively rare demographic bracket of those who worked with stopclock-capable hardware as early as the first half of the nineties.
    – Mike Nakis
    May 12 '17 at 17:47

Nope. This is a drastic simplification of how things actually work. For instance, waiting for user input on Windows involves polling for events, so you need to run CPU time to poll for events. You also need to render your current state which may change arbitrarily with respect to time, due to other OS events like network, or just plain timers.

Simply figuring out that you have nothing to do is not a free operation.

Then you have the OS's own background tasks, like paging memory. Confirm your system time with NTP. Ping the gateway to check if you're still on the network. Task-switch to other services for whatever they're supposed to be doing- e.g. Remote Desktop service to listen for people trying to RDP in to the machine.

Modern desktop CPUs can do all of these virtually instantaneously, so you could argue that the utilization is effectively zero, but it's certainly not actually zero nor constant.

  • 5
    Windows hasn't used polled IO for a couple of decades now. Feb 20 '17 at 23:25

As already mentioned, a CPU that is not running is also not doing anything useful so that is not a very interesting case. However, there are highly embedded battery-powered systems that spend 95% to 98% of their time asleep with no clock going to the CPU. A cardiac pacemaker is a good example. Only this way can such a system have a practical longevity with such a small battery (a typical pacemaker is explanted and replaced when its battery is depleted, approx. 5 years). Idle current consumptions are usually in the 10 microAmp range.

These systems are completely event driven and spend most of their time waiting for an interrupt that starts activity. There is little resemblance to conventional computing systems as they run on bare metal usually with no operating system (at least as we generally think of an OS). Power consumption dominates the design decisions and much processing is accomplished in custom hardware which consumes much less power than a CPU (turns out running a high speed CPU clock is one of the more power consuming activities in such a system). A modern low power SOC can run at approx. 100 microAmp/MHz current consumption to execute code. Consumption goes up from there as you start doing things that interact with the real world. There are still clocks running as they are necessary to detect happenings outside of the system (32 kHz watch crystals consume very little power).

So zero load -- not that interesting to me. Very low CPU load -- can still do some interesting and useful things. But the ultra-low power world is quite a different beast.


Unless someone has executed a CPU HLT (which is very, very rare) your CPU is actually always running at 100%.

When the O/S reports a CPU usage percentage, it is reporting a portion of the CPU cycles that are used for a certain type of thread (user, kernel, or both). There is another type of thread (the Idle Thread) which is always ready to be scheduled-- idle threads are not included in the CPU calculation. When the O/S says 75% CPU utilization, that means the idle thread was running for 25% of the clock cycles.

So if your question is-- can a CPU actually run at 0%, literally-- that is very rare unless you are issuing low-level hardware CPU instructions.

If your question is-- will the O/S ever report 0% utilization for user threads-- yes, this is certainly possible if you kill all your processes (and all those processes belonging to other users, including service accounts).

If you question is-- will the O/S ever report 0% utilization for both user and kernal threads-- yes, it is possible, in theory, if you have turned everything off and also killed all the processes that allow the O/S to function (e.g. receive keyboard input). You wouldn't be able to do anything with a system in that state. Meanwhile, the idle thread of course will still be running.

  • There are some cliparts you can borrow from these Intel articles about P-states: link 1, quite old, link 2
    – rwong
    Feb 20 '17 at 23:42
  • 1
    Most of the time, when the idle thread is "scheduled", the idle thread isn't "running". For the most part, the idle thread is just an accounting trick. It makes CPU scheduling and usage accounting algorithms much simpler if the scheduler can assume that there is always a process in ready state. When the idle thread gets scheduled though, the idle thread will either run HLT instruction or tell the processor to enter other power saving mode. HLT is a privileged instructions, so only the kernel in ring zero can execute it, user mode processes can't execute HLT.
    – Lie Ryan
    May 12 '17 at 16:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.