Something I've never quite understood is how a computer can operate without using all of its processing power. (Likely this confusion stems from a dreadful OS class in college.)

As far as I know, a thread (such as the OS's scheduler) has to be doing something at any given point in time. If there's nothing to do, it just loops until there is something to do. A loop of this nature, I would think, would always run as fast as it can, which would eat up all of a processor's computing power.

I'm guessing my misunderstanding is a wrong assumption that "if there's nothing to do, it just loops". I don't know what else it could do, however.

  • Well, first correction: In Windows at least, the OS's scheduler isn't a thread. As for "what else it could do" if there's nothing to do, read up on the HLT (halt) instruction. Read also about CPU power-saving states. – Jamie Hanrahan Jan 11 at 20:17

Computers have hardware timers that can be used to signal the processor when a particular length of time has passed. One such item is the High Precision Event Timer (HPET), and back in the history of things even the RTC could fulfil a similar purpose.

The CPU also has the ability to halt execution units using the HLT instruction and effectively put itself to sleep. No loops run and for all intents and purposes the CPU is dead except for hardware that waits for interrupt lines to be asserted.

Rather than spin-waiting through a loop the processor simply tells the hardware to alert it when a particular time has passed and then puts the core execution units to sleep. Once the time has passed the timer asserts an interrupt, which in turn wakes the CPU and execution starts again.

Low precision timers such as the RTC would work in a similar way, for every number of ticks you check the count on each tick and sleep until the next one comes along. It's a relatively low cost (processor power wise) way to implement wait states.

  • Hah, I've lived so long in the upper layers of software, where code just uses hardware for its own purposes, that it didn't even occur to me that hardware could be the one to signal the software. That embarrassing. – dx_over_dt Jan 9 at 20:19
  • 1
    @dx_over_dt in all fairness as far as the actual software is concerned it does just look like the CPU runs all the time, it's just that the CPU likes to take lots of naps and has a very loud, very accurate alarm clock and the OS scheduler spends a lot of time wandering around blearily saying "there's nothing to do here so let's have another 5 microsecond nap" or "jeez Program, are you still running? I haven't had a nap in ages so could you just ask for something from the disk so we can both go to sleep?" – Mokubai Jan 9 at 22:31

I'm sorry that OS class didn't cover this topic. It really should have. When I need to get into details I'm going to refer to Linux since it's both open-source and very popular, but other operating systems (as long as they have preemptive multitasking) are similar.

You're probably familiar with the PC hardware term "hardware thread". Linux calls them "CPUs". I'm also going to use "sleep" to talk about situations where hardware is saving power while waiting - this includes any time a CPU isn't 100% utilized.

At any time, a CPU can be be doing one of several things:

  • instructions triggered by an interrupt event [hi & si]

  • instructions needed to provide kernel services, such as translating between file-based IO and the storage devices. [sy]

  • application or server instructions in user mode [us & ni]

  • waiting for something to happen [id & wa]

  • instructions outside Linux's control [st]

[the codes are seen in the top program]

Interrupts are the key to understanding this. Whenever a hardware device needs attention from its driver, it sends a message to the interrupt controller, which routes it to a CPU, which makes a note of what it was doing and switches to the instructions for the corresponding device driver. Interrupts can also be generated by timer hardware or triggered by software. For example, when the CPU scheduler running on CPU 2 notices that CPU 5 should wake up or switch to a different task, it will send an interrupt.

There's an instruction which causes a CPU to do nothing and save power until it receives an interrupt. Linux creates an "idle task", which uses this instruction inside a loop - along with other things. The Linux idle loop also checks to see if a task is ready to run and may turn the "jiffy" timer off while a CPU is sleeping or do other power-management tasks.

Then that CPU's sleep is controlled by switching into and out of the idle task. Each CPU has one.

There's utility hardware on the CPU die which controls how much of a core is shut down while it is asleep - instructions on CPU 2 can control what CPU 5 is doing, etc. This is managed using ACPI firmware, and the different modes of power saving are called ACPI C-states. If the sleep is shallow enough then that core can still receive interrupts. So Linux also needs to tell the interrupt controller which cores are available for interrupts.

Like I said, interrupts are the key. Something happens in hardware - a block of data is ready from the hard drive, the USB controller is ready for more data, packets have arrived via Ethernet, time has elapsed, the GPU needs a chunk of memory - and a CPU core responds. If the CPU was lightly sleeping, that interrupt will wake it up. The device driver will run, the CPU will go back to its idle loop, and it check if there's a task ready to run. If so, the CPU will switch to that task and now it's running application instructions.

The reverse process, going to sleep, happens when the application asks for something and asks to go to sleep if necessary. For example, your web browser might ask if data has arrived from the network or input has been received from the user interface. It does this by a special instruction that switches to kernel mode. Linux is then running with privileges necessary to see the entire system. It checks for "ready-for-input" state. If ready, it returns to the browser's code, which continues receiving and processing the input.

But if Linux detects that an application isn't ready, it makes a note of what services the application is waiting for, marks the task as sleeping, and looks for some other task to do. If it doesn't find anything, it switches to the idle task, which is responsible for putting that CPU to sleep.

Later, when an interrupt happens and device drivers run, those notes will identify that the browser is ready to run again.

There are also code paths that decide whether to move tasks to a different CPU, change the sleep state of different CPU, and wake up deeply sleeping ones, all depending on load. Simple computers with only one CPU don't need that complexity, but PCs are generally multicore now.

So to recap:

  • the operating system puts software to sleep when that software needs something but that thing isn't ready or hasn't happened yet. It then tries to find some other software to run.

  • this can only happen when software asks the OS for something (a system-call). If an application enters an endless loop, it will use all the CPU time the OS gives it.

  • if there isn't any software for a CPU to run, the OS uses its idle task to put it to sleep.

  • (Switching to an idle task means that the previous task is free to move to another CPU if necessary - it isn't loaded in the CPU stuck there doing nothing. A single-CPU OS might not need an idle task, but it's still typically used.)

  • when hardware needs something or data arrives that creates an interrupt. This either interrupts a running CPU or wakes up a lightly sleeping one, and causes a device driver to run. At this point, OS book-keeping notices which sleeping software is now ready to run. At least one CPU is awake at this point - the one running the device driver - and others may be awoken if the OS desires. The OS decides which task should run (CPU scheduling) and switches if necessary.

  • if an application is interrupted, the OS will remember what it was doing and will eventually switch back to it.

  • if multiple tasks are ready to run at once, a timer interrupt (Linux calls it the "jiffy") will eventually cause the OS to switch tasks, even if there are no other interrupts on that CPU.

  • if an event is noticed on CPU A which means CPU B should wake up or might need to switch tasks, the OS running on A sends an interrupt to itself on B. In unusual situations, like forcing software to stop, CPU B might even be interrupted to tell it to go to sleep.

  • a "not-yet-ready" condition inside a system call puts software to sleep, hardware interrupts or software events cause hardware and software to wake up.

  • it's also possible to force software to sleep. Linux has "stop/trace" which is mostly used to pause software for debugging and "freeze" for making the entire system pause and save power. Both are triggered by software events, such as a debugger launching a program or the user clicking a "suspend to RAM" button.

New contributor
J Claire is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

Mokubai gives the correct answer for how sleep generally works. But even if the computer were spin-looping, it could still use less power than normal. Different instructions use different amounts of power, depending on what they do. Reading from RAM will use more power than reading from the CPU cache, and while it's in a tiny spin loop it should just use cache. While it's looping the parts of the CPU that perform arithmetic or interact with external devices are inactive, so they don't use any power. If it's a laptop, the screen will be shut down, and that should be a huge power saving.

This all isn't as good as going almost totally dead except for the event timer. But I think some operating systems have "low power mode" that's in between normal running and sleeping, which may incorporate some of this.

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.