Most Faults Cost a Microsecond and One Costs Ten Thousand
Last timeWhat Translation Costs
A missing block interrupts your program and hands control to the system. Four things can happen next, three of them cheap, and conflating them is why fault counts get ignored.
An entry pointing nowhere
Ask for a gigabyte of memory and the call returns immediately, on a machine
with far less than a gigabyte free. Nothing was allocated. Entries were added
to your map and marked as having nothing behind them.
This is not a trick played on you. It is the only sensible policy, because
programs routinely ask for more than they touch: a buffer sized for the worst
case, a sparse array, a library that reserves room at startup. Handing out real
memory for all of it would waste most of it.
So a map entry has a bit saying whether anything is actually there. When the
hardware walks the map and finds that bit clear, it cannot complete your
access. It stops your program mid-instruction and hands control to the system,
which is called a fault, and which sounds like an error and is not.
The three cheap outcomes
Group the outcomes by whether they touch a device, because that is a factor of
thousands and everything else is noise beside it.
A first touch of never-used memory is resolved by handing over a block of
zeros. The system keeps a supply of these, and zeroing is done in advance where
possible. Cost: a microsecond or so, almost all of it the interruption itself
rather than the work.
A block already resident under another name is resolved by pointing your entry
at it. This is what happens when you map a file a moment after another process
read it, or when two processes map the same library. No data moves at all.
A write to something shared is resolved by copying the block and pointing your
entry at the copy. This one does real work, four kilobytes of copying, but
four kilobytes of copying is still memory speed.
| outcome | nanoseconds | leaves memory | |
|---|---|---|---|
| fresh zeroed block | 1 | 1000 | 0 |
| already resident elsewhe | 2 | 1200 | 0 |
| copy a shared block | 3 | 3000 | 0 |
| read from a spinning dis | 4 | 8000000 | 1 |
| read from a solid state | 5 | 100000 | 1 |
The one that reaches storage
The fourth outcome is a different kind of event. The contents of the block are
on a device, the system issues a read, and your program is moved out of the
running state until the data arrives, which is exactly the blocking described
in the operating systems course.
The lesson stops here
2 more paragraphs to go
You have read the opening. The rest of the argument, the problems that check whether it landed, and the lines worth keeping at the end all come with a plan.
The first lesson of every course in the library reads the whole way through, free, so you can see exactly what the rest of them are.
See the planThe contentsThis is the reading half
Starting the course gives you your own copy of it. Every idea on every page has problems standing under it, marked with a reason rather than a tick, and any sentence you do not believe can be opened and argued with. None of that can happen on a page nobody owns.
The contents