Lecture 19 - Virtual Memory

Assignment 4

Just take the copy of the hello world device driver, then change the "Hello World" strings with the "Secret", and then modify the few functions that are just boilerplate. This really is just Minix Scavenger Hunt III.

Virtual Memory

The idea is just to pretend that we have unlimited memory. Pretend that we have as much memory as we so desire. What we are going to do is use our real memory to cache some of it.

Why does it work? It's because of the locality of reference (addresses that are near each other numerically are usually related in terms of content and usage). It also is a working set (temporal locality, things accessed near each other in time are related).

How does it work? Programs exist in virtual memory.

Virtual Memory	Real Memory
Divided into pages	Divided into frames
Resident Pages are hung in frames	...
Non-resident pages are stored on a backing store (some drive usually)
Translation is done (virt. to phys.) is done using a memory management unit (MMU) using a page table.

How do we do this? Using the figure above:

We have a virtual address constructed from the page number and offset in that page to get our physical address.
We use a bit to represent whether it's present in the virtual space.
- If it's present, translate to the address
- Else, get a PAGEFAULT error, and get the page from the disk (ughhhh!)
We can also add permission bits to keep track of:
- Read/Write/Execute rwx
- Reference recency R
- Has this been modified M
- Whether or not it's cacheable C

We've now replaced really expensive RAM for disk (essentially having infinite memory). However, we may have fragmentation due to larger page sizes. Further, each process has its own page table, so then each process has its own essential memory space.

Costs

Say we are on a 32-bit machine. Then our memory size is $2^{32} = 4 GB$ . Say our page size is $4 KB$ which is 12 digits long ( $n = 12$ ). Then our number of pages is $2^{20} \approx 1 million$ . Our page table size is $4 MB$ per processes ( $2^{22}$ . Where would we put this?

Put it in memory? Well even if we had a huge and fast memory bus, it's still a waste to move all the MMU between context switches!
Some valid options:

Limit the virtual memory size. But we wanted to assume that we had infinite memory! :(
Page The Page Tables: Instead of having one level of page table you have multiple levels

The problem is that this turns page misses from one trip to two trips (or even more). It does solve the size problem, but we pay for it in time. 3. Cache the translations: Put frequent translations into quick and easy cache.

The idea here is that we have a small, fully associative cache in the MMU with recent translations. This is known as a TLB, or translation lookaside buffer. It holds these translations for quick access:

on hit you have the translation and wicked fast
on miss you go get it from the page table
- This requires the HW to do both the fetching and know where the page table is.
- But doing it in software (while saving costs, in OS) will decrease speeds that HW can give.

Odds are though, that you'll get it from the TLB, and life will be good.

An Example

Say our memory size is based on a 64-bit system. So $2^{64}$ is our memory size. Now if our page size is still $2^{12}$ then our number of pages is $2^{52} = 4503599627370496$ . Then our page table size would be $\approx 36 PB$ . Notice how considerably bigger the page table size is. How could we best choose to store our page tables so that we can index better? Again the TLB here helps because recently translated TLBs are likely in there.

For nex time, we'll talk about still where to put the page tables (in memory, TLB, CPU, ...?).