Today's Outline
- Translation Lookaside Buffer
- page replacement
- page faults
Translation Lookaside Buffer
- TLB
- hardware-maintained associative table giving physical equivalents
for (a few) virtual page numbers
- 8-64 entries cached in the TLB, must be reloaded:
- by hardware (or by software), if using regular page tables
- by software, if using inverted page tables
- TLB works as a cache, so when the translation is not found
(and unless the TLB is reloaded by hardware), the result is a TLB miss,
handled by an interrupt handler
- the TLB miss handler must find the correct virtual-to-physical
translation and place it in the TLB
- the code for the TLB miss handler must be in memory that can
be accessed without a TLB miss!
page faults
- A virtual page is in one of two places:
- in physical memory, or
- on disk, usually in a reserved space called swap space
- a read-only virtual page loaded from disk (e.g. see mmap(2),
or when calling execve)
can also be backed by the regular disk rather than the swap space
- for any actual access, a page must be in physical memory
- an access to an unmapped page causes a page fault
- the page fault handler must map the page
- if the memory is full, the page fault handler must evict one
of the resident pages before it can map the new page
page replacement
- ideally, evict the page that will be referenced last among all
the pages in memory
- also, evicting a page that hasn't been modified avoids a write
to disk
- LRU (least recently used) uses the past to predict the future,
but requires high overhead -- have to timestamp each page usage,
then sort the timestamps
- instead, periodically mark all pages as unused, and update the
bit whenever a page is referenced. At the end of the period, any
pages with the bit still clear are Not Recently Used (NRU) and can
be evicted
page replacement implementation
- most MMUs do not mark pages used on each access
- instead, the OS can mark the page as unmapped (but still keep it
in physical memory)
- the first access to that page causes a page fault, which allows
the page fault handler to mark the page as used (as well as map the page
without any need to access the disk)
- to correctly keep the dirty bit recording
whether the page has been written, a page mapped in the previous
step can be marked read-only (if the access was a read), causing
an access violation page fault on the first write
- Copy-on-Write (COW) lets the page fault handler copy a page
if it is written to -- very useful for quick implementation of fork(2)
Copy on Write and fork
- fork() logically does a copy of the entire process
- this would be very expensive to implement with an actual copy
- instead, fork assigns the same physical pages to both processes,
and marks all of them read-only (even the ones that the process can
write to)
- when the hardware reports a protection violation, the page fault
handler can copy the relevant page only, leaving the rest shared
- in this way, fork is very cheap -- only the pages that are
actually modified must be copied
when demand exceeds supply
- virtual memory can give the illusion of more memory than there
is physical RAM
- however, even virtual memory is limited -- the sums of all the
process sizes should not exceed the size of RAM plus swap space
- also, once we start using swap, good performance depends on locality
- if many processes have to access virtual memory that is in
the swap space, they will make little progress
- while one page is being fetched from swap, another one (in the
working set) may get swapped out
- a system doing this is said to be thrashing, and seems
to be very slow
page fault outline
- locate a free physical page
- locate the desired virtual page on the disk
- issue a read request to the disk system
- when the page is ready, put it into memory (may be done by DMA)
- restart the process that page faulted by re-executing the
instruction that faulted
- kernel pages for the disk system should never be evicted -- we
refer to such pages as
locked, wired down, or pinned
- same for real-time processes and most or all interrupt handlers
- many kernels pin all the kernel memory
free page pool
- it is a good idea for the
OS to normally have some free pages, so page faults can be addressed quickly
- a process or thread (e.g. kswapd in linux -- see also
this
description) tries to make sure there are always pages available
- if not, candidate pages are freed, either directly for clean
pages, or by writing to disk the dirty pages