71

Looking at the source of strace I found the use of the clone flag CLONE_IDLETASK which is described there as:

#define CLONE_IDLETASK 0x00001000 /* kernel-only flag */

After looking deeper into it I found that, although that flag is not covered in man clone it is actually used by the kernel during the boot process to create idle processes (all of which should have PID 0) for each CPU on the machine. i.e. a machine with 8 CPUs will have at least 7 (see question below) such processes "running" (note quotes).

Now, this leads me to a couple of question about what that "idle" process actually do. My assumption is that it executes NOP operation continuously until its timeframe ends and the kernel assigns a real process to run or assign the idle process once again (if the CPU is not being used). Yet, that's a complete guess. So:

  1. On a machine with, say, 8 CPUs will 7 such idle processes be created? (and one CPU will be held by the kernel itself whilst no performing userspace work?)

  2. Is the idle process really just an infinite stream of NOP operations? (or a loop that does the same).

  3. Is CPU usage (say uptime) simply calculated by how long the idle process was on the CPU and how long it was not there during a certain period of time?


P.S. It is likely that a good deal of this question is due to the fact that I do not fully understand how a CPU works. i.e. I understand the assembly, the timeframes and the interrupts but I do not know how, for example, a CPU may use more or less energy depending on what it is executing. I would be grateful if someone can enlighten me on that too.

  • 17
    I had to resist the temptation to just write "Nothing at all" when I saw the title. – Vality Apr 26 '17 at 3:22
  • 4
    Most modern CPU's will dynamically lower their clock rate and power consumption when idling or under low load (dynamic frequency scaling, e.g. SpeedStep for Intel CPU's). If you overclock a CPU, it'll usually disable this behavior, causing the CPU to maintain max clock rate even when idling. – Nat Apr 26 '17 at 10:55
  • 2
    See also "ACPI power states": there are various ways in which a processor can stop executing instructions but still be wakeable. – pjc50 Apr 26 '17 at 11:18
82

The idle task is used for process accounting, and also to reduce energy consumption. In Linux, one idle task is created for every processor, and locked to that processor; whenever there’s no other process to run on that CPU, the idle task is scheduled. Time spent in the idle tasks appears as “idle” time in tools such as top. (Uptime is calculated differently.)

Unix seems to always have had an idle loop of some sort (but not necessarily an actual idle task, see Gilles’ answer), and even in V1 it used a WAIT instruction which stopped the processor until an interrupt occurred (it stood for “wait for interrupt”). Some other operating systems used busy loops, DOS, OS/2, and early versions of Windows in particular. For quite a long time now, CPUs have used this kind of “wait” instruction to reduce their energy consumption and heat production. You can see various implementations of idle tasks for example in arch/x86/kernel/process.c in the Linux kernel: the basic one just calls HLT, which stops the processor until an interrupt occurs (and enables the C1 energy-saving mode), the other implementations handle various bugs or inefficiencies (e.g. using MWAIT instead of HLT on some CPUs).

All this is completely separate from idle states in processes, when they’re waiting for an event (I/O etc.).

  • 3
    Heh, i see it now, thanks. play_dead() is a very nice mnemonic name for executing HALT. Wouldn't there be a risk to send HALT to every CPU and consequently hang? (i.e. reaching that situation, HALT every CPU, would be a bug in the kernel correct?) – grochmal Apr 25 '17 at 19:09
  • 29
    The CPU wakes up from HALT via an interrupt. – Johan Myréen Apr 25 '17 at 19:14
  • 1
    @JohanMyréen - Cool, that makes sense. In such a case even an IRQ interrupt from an input device would wake it back up. Thanks. – grochmal Apr 25 '17 at 20:25
  • 15
    Or more reliably, the timer interrupt... (Tickless handling is another kettle of fish.) – Stephen Kitt Apr 25 '17 at 20:31
  • 3
    @EJP indeed, it's a pretty common instruction, even though it has different names in different architectures. – immibis Apr 26 '17 at 0:31
49

In the textbook design of a process scheduler, if the scheduler doesn't have any process to schedule (i.e. if all the processes are blocked, waiting for input), then the scheduler waits for a processor interrupt. The interrupt may indicate input from a peripheral (user action, network packet, completed read from a disk, etc.) or may be a timer interrupt that triggers a timer in a process.

Linux's scheduler doesn't have special code for a nothing-to-do case. Instead, it encodes the nothing-to-do case as a special process, the idle process. The idle process only gets scheduled when no other process is schedulable (it effectively has an infinitely low priority). The idle process is in fact part of the kernel: it's a kernel thread, i.e. a thread that executes code in the kernel, rather than code in a process. (More precisely, there's one such thread for each CPU.) When the idle process runs, it performs the wait-for-interrupt operation.

How wait-for-interrupt works depends on the processor's capabilities. With the most basic processor design, that's just a busy loop —

nothing:
    goto nothing

The processor keeps running a branch instruction forever, which accomplishes nothing. Most modern OSes don't do this unless they're running on a processor where there's nothing better, and most processors have something better. Rather than spend energy doing nothing except heating the room, ideally, the processor should be turned off. So the kernel runs code that instructs the processor to turn itself off, or at least to turn off most of the processor. There must be at least one small part that stays powered on, the interrupt controller. When a peripheral triggers an interrupt, the interrupt controller will send a wake-up signal to the main (part of) the processor.

In practice, modern CPUs such as Intel/AMD and ARM have many, complex power management settings. The OS can estimate how long the processor will stay in idle mode and will choose different low-power modes depending on this. The modes offer different compromises between power usage while idle, and the time it takes to enter and exit the idle mode. On some processors the OS can also lower the clock rate of the processor when it finds that processes aren't consuming much CPU time.

  • 5
    Note that even the most very basic embedded CPUs like AVR-based microcontrollers have a WFI (Wait For Interrupt) instruction, even though that instruction may be equivalent to NOP depending on the exact model. – Jonas Schäfer Apr 26 '17 at 12:30
  • @JonasWielicki I thought you'd usually just go into a tight loop if you had nothing to do, or you could go into a low-power state and wait for the interrupt to knock you out of it (lower power states usually requiring more "metal" interrupts). – Nick T Apr 26 '17 at 20:40
  • 1
    @JonasWielicki Architectures designed for embedded systems care about power management so WFI is important there. Many older architectures have no such thing. The original 8086 architecture didn't, AFAIR. Does 68k have WFI? Is it a standard feature on MIPS? My familiarity with low-level programming is mostly on ARM, where low power consumption is a matter of course and WFI is only the tip of the power management iceberg. – Gilles Apr 27 '17 at 7:56
  • 1
    @Gilles 8086 had a halt instruction. See en.m.wikipedia.org/wiki/HLT_(x86_instruction) The instruction included power saving functionality only since 80486 DX4. Looking back into history HLT was already in 8080 and derivates (like Z80). – pabouk Apr 27 '17 at 12:19
  • 1
    @pabouk HLT could power down SL variants of the 386 and 486, before the DX4 came out (the Wikipedia article is incorrect). – Stephen Kitt May 2 '17 at 18:50
0

No, an idle task does not waste CPU cycles. The scheduler simply does not select an idle process for execution. An idle process is waiting for some event to happen so that it can continue. For example, it can be waiting for input in a read() system call.

By the way, the kernel is not a separate process. Kernel code is always executed in the context of a process (well, except for the special case of a kernel thread), so it's not correct to say "and one CPU will be held by the kernel itself whilst no performing userspace work".

  • 3
    Hmmm... I don't think that is the kind of idle process that is created by CLONE_IDLETASK. Had it been then it would not need to be created at all, i.e. had the scheduler ignored the kernel idle processes on the CPUs it would not need create any processes for them during boot. (the DW is not mine though :) ) – grochmal Apr 25 '17 at 18:27
  • A little googling reveals that CLONE_IDLETASK is a kernel-internal flag that was introduced around kernel version 2.5.14 in 2002 and later removed in 2004. – Johan Myréen Apr 25 '17 at 18:43
  • "an" idle process but not "the" idle process. – immibis Apr 26 '17 at 0:32

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.