Lecture 20 - Filesystems, Virtual Memory Algorithms

Look at DEV_GATHER and DEV_SCATTER from Lecture 13 - Disk Drives. There was a question asked there about permission errors encountered here.

More on Virtual Memory

Last time we talked about:

pages, frames
translation
PAGE_FAULTS! (if we have a reference to a page that isn't resonant, then we get it from storage and put it somewhere)

For page-faults, which page are we going to replace? There are many policies that we could use (similar to context switches):

Replace the page that won't be used for the longest time. (Optimal Strategy)
- Pros: you can't do better than this. This is literally the optimal strategy.
- Cons: requires perfect knowledge of the future (how do you know how long it'll be used for?)
- This is a good benchmark to compare against though.
LOL Completely random. Just pick one.
- Pros: Simple, maybe you'll be lucky.
- Cons: you may abort the page that the program for tracking the page table is running on!
Not Recently Used
- Prefer any unmodified page, since we don't have to go to storage to let it know that it's been modified.
- Divide into 4 categories, based on reference bit $R$ and modified bit $M$ :

	$\overset{―}{R}$	$R$
$\overset{―}{M}$	0	2
$M$	1	3
You'll evict random page from lowest non-empty category (see the table). Periodically, you'll want to evict (clear) the $R$ bit. We still have the problem with (2) where we probabilistic-ally can remove the page that our program is running on, but it's less likely since it's referenced $R$ and thus requires other pages to be thrown out first.

Keep a FIFO to track and evict the oldest page.
- Pros: It's simple. It evicts the old stuff.
- Cons: You are guarunteed to evict older pages for the sake of them being old.
Combine (3) and (4). Second Chance.
- Use a FIFO to track old pages; however, if the head has been re-referenced, clear the $R$ bit and send back to the end.

Clock Algorithm

Due to the nature of the clockwork structure of the FIFO, (5) above is called the Clock Algorithm.

Least Recently Used (LRU)
- Pros: Approximately Optimal.
- Desc: Keep a list (FIFO) where the head is the most recently used, and the tail is the oldest(ly?) used. Everytime you reference $R$ a page you put that node to the head of the list.
- Cons: It's prohibitive. Because this runs on memory itself, then the reordering really increases the runtime of getting that extra memory.
Not Frequently Used (NFU)
- Desc: Have a counter to our page table. Every page starts at 0. Periodically (not on every cpu cycle tick, but often enough), we add the reference $R$ bit to the counter and clear the $R$ bit (effectively increasing the counters for thos that are referenced frequently). On a PAGE_FAULT evict the page with the lowest counter.
- Every program usually context switches with the other programs, so then they stop getting referenced, so this would create the problem of "tenured" pages that are just always being in the context, and thus are always referenced and just stay in the page table. Further it chokes your other programs into having a slower memory reference time.
  - To fix this, change the counter to a shift register & shift $R$ in as the Most Significant bit. Essentially this is just weighing the more recent actions by shifting a bunch of $1$ 's, but over time if you are not doing any work then $0$ 's get shifted in and thus evict those pages.