What is the main purpose of the swapper process in Unix?

Solution 1:

It hasn't been a swapper process since the 1990s, and swapping hasn't really been used since the 1970s.

Unices stopped using swapping a long time ago. They've been demand-paged operating systems for a few decades — since System V R2V5 and 4.0BSD. The swapper process, as was, used to perform process swap operations. It used to swap entire processes — including all of the kernel-space data structures for the process — out to disc and swap them back in again. It would be woken up, by the kernel, on a regular basis, and would scan the process table to determine what swapped-out-and-ready-to-run processes could be swapped in and what swapped-in-but-asleep processes could be swapped out. Any textbook on Unix from the 1980s will go into this in more detail, including the swap algorithm. But it's largely irrelevant to demand-paged Unices, even though they retained the old swap mechanism for several years. (The BSDs tried quite hard to avoid swapping, in favour of paging, for example.)

Process #0 is the first process in the system, hand-crafted by the kernel. It fork()s process 1, the first user process. What it does other than that is dependent from what Unix the operating system actually is. As mentioned, the BSDs before FreeBSD 5.0 retained the old swapper mechanism, and process #0 simply dropped into the swapper code in the kernel, the scheduler() function, after it had finished system initialization. System V was much the same, except that process #0 was conventionally named sched rather than swapper. (The names are pretty much arbitrary choices.) In fact, most — possibly all — Unices had a (largely unused) old swapper mechanism that hung around as process #0.

Linux, traditionally, has been somewhat different to the Unices, in that process #0 is the idle process, running cpu_idle(). It simply does nothing, in an infinite loop. It exists so that there's always a task ready to be scheduled.

Even this is an out-of-date description. The late 1980s and early 1990s was the advent of multi-threading operating systems, as a result of which process #0 became simply the system process. In the world of old single-threaded Unices, one could only get a separate flow of execution to do a continuous kernel task by fork()ing a process. So all of the kernel tasks (vmdaemon, pagedaemon, pagezero, bufdaemon, syncer, ktrace, and so forth on FreeBSD systems, for example) were low-numbered processes, fork()ed by process #0 after it fork()ed ìnit. In multiple-threaded Unices, it makes no sense to create a whole new process context for something that runs entirely in kernel space, and doesn't need an address space, file descriptor table, and whatnot all to itself. So all of these tasks became (essentially) threads, sharing the address space of a single system process.

Along the way, several Unices fianlly lost the old swapper mechanism, that they were trying their utmost to avoid ever using anyway. OpenBSD's initialization code now simply drops into a while(1) tsleep(…); loop, for example, with no swapping mechanism anywhere.

So nowadays process #0 on a Unix is the system process, which effectively holds a number of kernel threads doing a number of things, ranging from page-out operations, through filesystem cache flushes and buffer zeroing, to idling when there's nothing else to run.

Solution 2:

Process 0 is a special process (called swapper or idle process) which runs when the system is idle, i.e. no other process is scheduled. It is the only process which can invoke the idle() system call.

This is the first process to be spawned, which then creates init (PID 1) which starts other processes.

root         1     0 /sbin/init

You can also check man idle.

See also: Understanding the Linux Kernel – Process Scheduling

Solution 3:

The reason is historical and programatic. The idle task is the task running, if no other task is runnable, like you said it. It has the lowest possible priority, so that's why it's running of no other task is runnable.

Programatic reason: This simplifies process scheduling a lot, because you don't have to care about the special case: "What happens if no task is runnable?", because there always is at least one task runnable, the idle task. Also you can count the amount of cpu time used per task. Without the idle task, which task gets the cpu-time accounted no one needs?

Historical reason: Before we had cpus which are able to step-down or go into power saving modes, it HAD to run on full speed at any time. It ran a series of NOP-instructions, if no tasks were runnable. Today the scheduling of the idle task usually steps down the cpu by using HLT-instructions (halt), so power is saved. So there is a functionality somehow in the idle task in our days.

In Windows you can see the idle task in the process list, it's the idle process.