Brain Food for Hackers

• RSS

• Blog
• Archives

What Does an Idle CPU Do?

Oct 29th, 2014

In the last post I said the fundamental axiom of OS behavior is that at anygiven time, exactlyone and only one task is active on a CPU. But ifthere’s absolutely nothing to do, then what?

It turns out that this situation is extremely common, and for most personalcomputers it’s actually the norm: an ocean of sleeping processes, all waiting onsome condition to wake up, while nearly 100% of CPU time is going into themythical “idle task.” In fact, if the CPU is consistently busy for a normaluser, it’s often a misconfiguration, bug, or malware.

Since we can’t violate our axiom, some task needs to be active on a CPU.First because it’s good design: it would be unwise to spread special cases allover the kernel checking whether thereis in fact an active task. A design isfar better when there are no exceptions. Whenever you write anif statement,Nyan Cat cries. And second, we need to do something with all those idle CPUs,lest they get spunky and, you know, create Skynet.

So to keep design consistency and be one step ahead of the devil, OS developerscreate anidle task that gets scheduled to run when there’s no other work.We have seen in the Linuxboot process that the idle task is process 0,a direct descendent of the very first instruction that runs when a computer isfirst turned on. It is initialized inrest_init, where init_idle_bootup_taskinitializes the idle scheduling class.

Briefly, Linux supports different scheduling classes for things like real-timeprocesses, regular user processes, and so on. When it’s time to choose a processto become the active task, these classes are queried in order of priority. Thatway, the nuclear reactor control code always gets to run before the web browser.Often, though, these classes returnNULL, meaning they don’t have a suitableprocess to run – they’re all sleeping. But the idle scheduling class, which runslast, never fails: it always returns the idle task.

That’s all good, but let’s get down to just what exactly this idle task isdoing. So here iscpu_idle_loop, courtesy of open source:

cpu_idle_loop

1234567891011

while (1) {    while(!need_resched()) {        cpuidle_idle_call();    }    /*      [Note: Switch to a different task. We will return to this loop when the      idle task is again selected to run.]    */    schedule_preempt_disabled();}

I’ve omitted many details, and we’ll look at task switching closely later on,but if you read the code you’ll get the gist of it: as long as there’s no needto reschedule, meaning change the active task, stay idle. Measured in elapsedtime, this loop and its cousins in other OSes are probably the most executedpieces of code in computing history. For Intel processors, staying idletraditionally meant running thehalt instruction:

native_halt

1234

static inline void native_halt(void){  asm volatile("hlt": : :"memory");}

hlt stops code execution in the processor and puts it in a halted state. It’sweird to think that across the world millions and millions of Intel-like CPUsare spending the majority of their time halted, even while they’re powered up.It’s also not terribly efficient, energy wise, which led chip makers to developdeeper sleep states for processors, which trade off less power consumption forlonger wake-up latency. The kernel’scpuidle subsystem isresponsible for taking advantage of these power-saving modes.

Now once we tell the CPU to halt, or sleep, we need to somehow bring it back tolife. If you’ve read thelast post, you might suspect interrupts areinvolved, and indeed they are. Interrupts spur the CPU out of its halted stateand back into action. So putting this all together, here’s what your systemmostly does as you read a fully rendered web page:

Other interrupts besides the timer interrupt also get the processor movingagain. That’s what happens if you click on a web page, for example: your mouseissues an interrupt, its driver processes it, and suddenly a process is runnablebecause it has fresh input. At that point need_resched() returns true, and theidle task is booted out in favor of your browser.

But let’s stick to idleness in this post. Here’s the idle loop over time:

In this example the timer interrupt was programmed by the kernel to happen every4 milliseconds (ms). This is thetick period. That means we get 250 ticks persecond, so the tick rate ortick frequency is 250 Hz. That’s a typical valuefor Linux running on Intel processors, with 100 Hz being another crowd favorite.This is defined in theCONFIG_HZ option when you build the kernel.

Now that looks like an awful lot of pointless work for an idle CPU, and it is.Without fresh input from the outside world, the CPU will remain stuck in thishellish nap getting woken up 250 times a second while your laptop battery isdrained. If this is running in a virtual machine, we’re burning both power andvaluable cycles from the host CPU.

The solution here is to have a dynamic tick so that when the CPU is idle, thetimer interrupt is either deactivated or reprogrammed tohappen at a point where the kernel knows there will be work to do (forexample, a process might have a timer expiring in 5 seconds, so we must notsleep past that). This is also calledtickless mode.

Finally, suppose you have one active process in a system, for examplea long-running CPU-intensive task. That’s nearly identical to an idle system:these diagrams remain about the same, just substitute the one process for theidle task and the pictures are accurate. In that case it’s still pointless tointerrupt the task every 4 ms for no good reason: it’s merely OS jitter slowingyour work ever so slightly. Linux can also stop the fixed-rate tick in thisone-process scenario, in what’s calledadaptive-tick mode. Eventually,a fixed-rate tick may be gone altogether.

That’s enough idleness for one post. The kernel’s idle behavior is an importantpart of the OS puzzle, and it’s very similar to other situations we’ll see, sothis helps us build the picture of a running kernel. More next week,RSS andTwitter.

Posted by Gustavo Duarte Oct 29th, 2014Internals,Linux, Software Illustrated