§2.1Virtualizing The CPU

Before asking what an operating system is, the book asks a more basic question: what happens when a program runs? The answer, at its core, is almost embarrassingly simple — and everything else in this book is about what’s layered on top of it.

What happens when a program runs?

A running program does one very simple thing: it executes instructions. Millions — nowadays billions — of times every second, the processor:

1. fetches an instruction from memory,
2. decodes it (figures out which instruction it is), and
3. executes it (adds two numbers, accesses memory, checks a condition, jumps to a function, …),

then moves on to the next instruction, and the next, until the program completes. This is the basic Von Neumann model von neumann model The fetch–decode–execute model: a processor runs one instruction at a time, in order. defined in ch. 2 — open in glossary of computing.

Sounds simple. But while a program runs, a lot of other wild things are going on, all with one primary goal: making the system easy to use.

There is a body of software responsible for making it easy to run programs (even seemingly many at the same time), letting programs share memory, letting programs talk to devices, and other fun stuff. That body of software is the operating system operating system Software that makes the system easy to use by virtualizing resources, handling concurrency, and storing data persistently. defined in ch. 2 — open in glossary (OS), so called because it is in charge of making sure the system operates correctly and efficiently — in an easy-to-use manner.

The primary technique the OS uses is virtualization virtualization Transforming a physical resource (CPU, memory, disk) into a more general, powerful, easy-to-use virtual form. defined in ch. 2 — open in glossary : it takes a physical resource — processor, memory, disk — and transforms it into a more general, powerful, easy-to-use virtual form of itself. That’s why people sometimes call the OS a virtual machine.

Of course, to use the virtual machine — run a program, allocate memory, open a file — you need a way to ask. So every OS exports interfaces (APIs): a typical OS exports a few hundred system calls system call A controlled entry into the OS (via trap) that raises the privilege level so the kernel can do work on a program's behalf. defined in ch. 2 — open in glossary covering running programs, accessing memory and devices, and so on. Because of this, we sometimes say the OS provides a standard library to applications.

Finally, since virtualization lets many programs share the CPU, memory, and devices all at once, the OS is also called a resource manager resource manager The OS's role of sharing the CPU, memory, and disk among many programs efficiently and fairly. defined in ch. 2 — open in glossary : CPU, memory, and disk are the system’s resources, and it’s the OS’s job to manage them — efficiently, or fairly, or with whatever goal matters most. To see the OS doing all this, the book runs some real code — starting with the CPU.

2.1 Virtualizing The CPU

Figure 2.1 is the book’s first program. It doesn’t do much: Spin() (a helper from the book’s common.h) repeatedly checks the time and returns once it has run for a second; then the program prints the string the user passed on the command line, and repeats. Forever.

#include <stdio.h>
#include <stdlib.h>
#include <sys/time.h>
#include <assert.h>
#include "common.h"

int
main(int argc, char *argv[])
{
    if (argc != 2) {
        fprintf(stderr, "usage: cpu <string>\n");
        exit(1);
    }
    char *str = argv[1];
    while (1) {
        Spin(1);
        printf("%s\n", str);
    }
    return 0;
}

Figure 2.1: Simple Example: Code That Loops And Prints (cpu.c)

Compile and run it on a system with a single processor (or CPU), and it behaves exactly as you’d expect — one line per second until you kill it with Control-c:

prompt> gcc -o cpu cpu.c -Wall
prompt> ./cpu "A"
A
A
A
A
^C
prompt>

Now the interesting part. Run four instances of the same program on that same single-CPU machine (the & backgrounds each job so the shell takes the next command immediately):

prompt> ./cpu A & ./cpu B & ./cpu C & ./cpu D &
[1] 7353
[2] 7354
[3] 7355
[4] 7356
A
B
D
C
A
B
D
C
A
...

Figure 2.2: Running Many Programs At Once

Even though there is only one processor, all four programs seem to be running at the same time. How does this magic happen?

Step through what is actually going on:

It is the operating system, with some help from the hardware, that creates this illusion — the illusion that the system has a very large number of virtual CPUs. Turning a single CPU (or a small set of them) into a seemingly infinite number of CPUs, letting many programs seemingly run at once, is what the book calls virtualizing the CPU — the focus of Part I.

Two loose ends, both of which the book pulls on for the rest of Part I:

• How do you ask the OS to run (or stop) programs at all? Through those APIs — the system calls. They are the main way users and programs interact with the OS, and the process-related ones get their own chapters soon.
• If two programs want to run at the same moment, which should run? Look back at the timeline: the machine printed A B D C, not A B C D — somebody chose that order. That question is answered by a policy policy An OS decision rule that answers "which/what next?" questions, e.g. which program runs next. defined in ch. 2 — open in glossary of the OS. Policies answer “which/what next?” questions all over the OS, and studying them alongside the mechanisms that make switching possible is exactly the plan: the role of the OS as a resource manager, in action.

This page covered the chapter’s framing plus its first piece; the same demo style continues with memory and threads in the next two sections. And if the dialogue framing of all this rings a bell — the three pieces were first named in the opening dialogue.