Effective memory access time:
Where:
T_{memory} = 100 ns
T_{disk} = 25 ms
p_{miss} = 0.0001 (in this case, will give slow down by a factor of 250)
Copy-on-write:
copy PTEs when fork, but mark both PTEs as read-only ("special-kind-of-read-only")
page fault:
ZFOD: zero-filled-on-demand
mmap():
map file into memory, return pointer to mapped region
avoid serializing pointer-based data structure
can lazy load file into memory (page fault trigger read() calls)
if two program map to the same file, they can share the same physical page (and faster)
Page eviction daemon: scan for frames once a while (swappiness)
pick a frame
store to disk
How to choose a page to evict:
Bad: FIFO, Optimal, LRU
Practical: LRU approximation
Research: ARC (Adaptive Replacement Cache), CAR (Clock with Adaptive Replacement), CART (CAR with Temporal Filtering), S3-FIFO
S3-FIFO: many items (26%-72%) are referenced just once, delete them is fine. Update cache entries require locking, so don't.
How many frame should an address space have?
figure out minimum frames needed to successfully run a program (bad)
each program has some percentage of memory (bad)
each program can only keep some percentage of its working set
Thrashing: a program can only run given 20 frames, but the system keep wanting it to have only 19 frames. So the program keep generating page faults, denial of service attack on paging system.
Balancing Fault Rate: keep system-wide "average fault rate", if a process fault too much, increase its quota, if a process fault too little, decrease its quota. (fair fault rate)
This problem isn't just OS problem, linker can help keeping relevant code together.
// LRU approximation with "clock" algorithm
boolean reference[nframes]; // reference bit for each frame
int choose_victim() {
static int nextpage = 0;
while (reference[nextpage] == 1) {
reference[nextpage] = 0;
nextpage = (nextpage + 1) % nframes;
}
return nextpage;
}

Table of Content