Source: Operating Systems: Three Easy Pieces (OSTEP) — Chapter 11, Arpaci-Dusseau & Arpaci-Dusseau
Summary Dialogue on CPU Virtualization
This chapter is a conversation — Professor and Student look back at CPU virtualization. Use it to check what stuck before you move on to concurrency or virtual memory.
The conversation
Part I — mechanisms and philosophy
Professor: So, Student, did you learn anything?
Student: Well, Professor, that seems like a loaded question. I think you only want me to say “yes.”
Professor: That’s true. But it’s also still an honest question. Come on, give a professor a break, will you?
Student: OK, OK. I think I did learn a few things. First, I learned a little about how the OS virtualizes the CPU. There are a bunch of important mechanisms that I had to understand to make sense of this: traps and trap handlers, timer interrupts, and how the OS and the hardware have to carefully save and restore state when switching between processes.
Professor: Good, good!
Student: All those interactions do seem a little complicated though; how can I learn more?
Professor: Well, that’s a good question. I think there is no substitute for doing; just reading about these things doesn’t quite give you the proper sense. Do the class projects and I bet by the end it will all kind of make sense.
Student: Sounds good. What else can I tell you?
Professor: Well, did you get some sense of the philosophy of the OS in your quest to understand its basic machinery?
Student: Hmm… I think so. It seems like the OS is fairly paranoid. It wants to make sure it stays in charge of the machine. While it wants a program to run as efficiently as possible (and hence the whole reasoning behind limited direct execution), the OS also wants to be able to say “Ah! Not so fast my friend” in case of an errant or malicious process. Paranoia rules the day, and certainly keeps the OS in charge of the machine. Perhaps that is why we think of the OS as a resource manager.
Professor: Yes indeed — sounds like you are starting to put it together! Nice.
Student: Thanks.
Part II — policies and pragmatism
Professor: And what about the policies on top of those mechanisms — any interesting lessons there?
Student: Some lessons to be learned there for sure. Perhaps a little obvious, but obvious can be good. Like the notion of bumping short jobs to the front of the queue — I knew that was a good idea ever since the one time I was buying some gum at the store, and the guy in front of me had a credit card that wouldn’t work. He was no short job, let me tell you.
Professor: That sounds oddly rude to that poor fellow. What else?
Student: Well, that you can build a smart scheduler that tries to be like SJF and RR all at once — that MLFQ was pretty neat. Building up a real scheduler seems difficult.
Professor: Indeed it is. That’s why there is still controversy to this day over which scheduler to use; see the Linux battles between CFS, BFS, and the O(1) scheduler, for example. And no, I will not spell out the full name of BFS.
Student: And I won’t ask you to! These policy battles seem like they could rage forever; is there really a right answer?
Professor: Probably not. After all, even our own metrics are at odds: if your scheduler is good at turnaround time, it’s bad at response time, and vice versa. As Lampson said, perhaps the goal isn’t to find the best solution, but rather to avoid disaster.
Student: That’s a little depressing.
Professor: Good engineering can be that way. And it can also be uplifting! It’s just your perspective on it, really. I personally think being pragmatic is a good thing, and pragmatists realize that not all problems have clean and easy solutions. Anything else that caught your fancy?
Student: I really liked the notion of gaming the scheduler; it seems like that might be something to look into when I’m next running a job on Amazon’s EC2 service. Maybe I can steal some cycles from some other unsuspecting (and more importantly, OS-ignorant) customer!
Professor: It looks like I might have created a monster! Professor Frankenstein is not what I’d like to be called, you know.
Student: But isn’t that the idea? To get us excited about something, so much so that we look into it on our own? Lighting fires and all that?
Professor: I guess so. But I didn’t think it would work!
What you should take away
Mechanisms (how)
| Piece | Role |
|---|---|
| Process | Illusion of a private machine — states, PCB, time sharing |
| fork / exec / wait | Create and control processes; shell pattern |
| User / kernel mode | Restricted vs privileged execution |
| Trap + return-from-trap | Safe entry/exit for system calls |
| Timer interrupt | OS regains CPU without cooperation |
| Context switch | Save one process, restore another |
The hardware and OS cooperate: traps, privilege levels, trap tables, and careful save/restore on every switch.
Policies (which)
| Idea | Lesson |
|---|---|
| Short jobs first (SJF) | Great turnaround — if you knew lengths |
| Round-robin | Good response — worse turnaround |
| MLFQ | Learn from behavior; boost; anti-gaming |
| Fair share | Tickets / vruntime — target CPU fractions |
| Multiprocessor | SQMS vs MQMS; affinity; work stealing |
No silver bullet: good turnaround often fights good response time. Linux still debates CFS, BFS, O(1), …
Philosophy (why)
The Student’s best line: the OS is paranoid but pragmatic.
- Limited direct execution — run programs fast and stay in charge (“Ah! Not so fast, my friend”).
- Resource manager — the OS parcels out CPU (and later memory, disk, …) among competing programs and users.
- Avoid disaster (Lampson) — pragmatic engineering beats chasing one perfect metric.
- Gaming schedulers — policy choices have security implications (shared clouds, EC2, …).
- Do, don’t only read — class projects and simulators (
process-run.py,mlfq.py, …) cement the ideas.
Interactive: walk the arc
Check your understanding
CPU virtualization — full review
1 / 6Limited direct execution means the OS…
Pick an answer to see if you are right.
Coding challenge — map concept to layer
One quick Python drill: is each item a mechanism (how) or policy (which)?
Where you’ve been (links)
| # | Topic | Path |
|---|---|---|
| 4 | The Process Abstraction | States, time sharing |
| 5 | Process API | fork, exec, wait |
| 6 | Limited Direct Execution | Traps, timers, context switch |
| 7 | Scheduling Introduction | FIFO, SJF, STCF, RR |
| 8 | MLFQ | Learn-from-history scheduler |
| 9 | Proportional Share | Lottery, stride, CFS |
| 10 | Multiprocessor Scheduling | SQMS, MQMS, affinity |
Lessons follow OSTEP Part I: process → API → LDE → Ch. 7 scheduling intro → MLFQ → proportional share → multiprocessor → Ch. 11 recap.
Summary
| Theme | One line |
|---|---|
| Virtualization | Many processes, few CPUs — illusion via time sharing |
| Mechanisms | LDE, traps, timers, context switch |
| Policies | MLFQ, fair share, multiprocessor queues |
| Philosophy | Paranoid OS; pragmatic tradeoffs; do the projects |
| No perfect scheduler | Pick goals; avoid disaster; watch for gaming |
Next: Memory Virtualization Dialogue — Part III begins: virtual addresses, isolation, and the roadmap to paging.
Further Reading
- Remzi & Andrea Arpaci-Dusseau — Operating Systems: Three Easy Pieces Ch. 11
- Revisit simulators and homework:
process-run.py,mlfq.py,lottery.py,multi.pyon your machine