the operating system perspective
DESCRIPTION
The Operating System Perspective. RTE's memory management services memory management mechanism, as viewed from the OS perspective opposed to the programming language perspective. Virtual Memory (VM ). scheme enables each process to have its own independent view of memory - PowerPoint PPT PresentationTRANSCRIPT
SPL/2010 1SPL/2010
The Operating System Perspective
SPL/2010 2SPL/2010
● RTE's memory management services● memory management mechanism,
as viewed from the OS perspective● opposed to the programming
language perspective
SPL/2010 3SPL/2010
Virtual Memory (VM)● scheme enables each process to have
its own independent view of memory● OS (with help from the hardware)
maps process memory into real memory
● illusion that more virtual memory exists than physical memory
SPL/2010 4SPL/2010
Virtual Memory (VM)● process is presented with a virtual
address space, 0-232 ● process thinks is running alone● CPU has no notion of virtual memory ● MMU (memory management unit) –
translates virtual address into physical and sends it to CPU
SPL/2010 5SPL/2010
Virtual Memory (VM)● there is less RAM installed than 232
● we assume most processes will actually use less RAM than full virtual space.
● when not enough memory in RAM, use disk and swap between RAM and disk
● heavy penalty to go to disk to fetch data
SPL/2010 6SPL/2010
Virtual Memory (VM)● locality of reference: processes
cluster memory references to small subsets of VM
● virtual memory (caching) is efficient
SPL/2010 7SPL/2010
Paging - VM implementation● physical memory is broken down into
pieces of small size 4K● physical memory can now be seen as
an array of physical pages● virtual address space is broken into
pages of same size 4K● virtual page is mapped to
physical page
SPL/2010 8SPL/2010
SPL/2010 9SPL/2010
Finding the Page of an Address● an address addr resides:
● page number addr >> log(page size) addr/ page size
● offset addr % page size
SPL/2010 10SPL/2010
● how to break down a virtual address into virtual page number and offset when using pages of 4k on a 32 bit CPU:
SPL/2010 11SPL/2010
Page Tables● translation table for each process● maps virtual address space into the
physical memory● OS a translation table for each
process: Page Table
SPL/2010 12SPL/2010
Page Tables● each row represents a virtual page
and ● column holds the physical page
address in which the virtual page resides
● register stores a pointer to table. ● in context switch, os updates register
with current process' page table address
SPL/2010 13SPL/2010
Address lifecycle● process executes code involving
memory address, addr● MMU finds the virtual page
number, vpn, in which addr resides● MMU locates vpn entry in page table
- retrieves physical page number ppn ● MMU replaces addr by paddr
paddr = (addr % page_size) + (ppn << log(page_size)
SPL/2010 14SPL/2010
example● assume page size = 4096bytes (212
1<<12), ● virtual address 0x80403040 ● vpn = 0x8040 ● by page table vpn->ppn=0x1020● paddr= 0x10203040
SPL/2010 15SPL/2010
TLB and Context Switches● TLB – translation lookaside buffer● caches recent translation made by
MMU. ● when MMU needs to locate a physical
page for a virtual one - first checks TLB
● in a context switch, TLB is irrelevant
SPL/2010 16SPL/2010
Demand Paging and Swap● process has memory size of 232
● what if each process access so much memory?
● a process does not need all of its memory all of the time
● swap unneeded data from memory, and restore it when needed
SPL/2010 17SPL/2010
Implementation● metadata attribute for each page:1. Access rights: either read, write,
execute or a combination thereof2. Present bit: is the page mapped to a
physical page at all?3. Dirty bit: has the page been written
to since loading it into physical memory?
SPL/2010 18SPL/2010
Present bit● OS evicts P from main memory -
writes P ● OS sets present bit of P to 0● if in MMU translate page is not
present, MMU throws page fault interrupt - calls OS page fault handler● OS reads saved page from disk into
physical page, and update page table
SPL/2010 19SPL/2010
Present bit● lazy page allocation:
● pretend to allocate the memory: OS updates the page tables of the process
● the present bit is cleared from each of these pages
SPL/2010 20SPL/2010
Dirty bit● a page needs to be evicted, but the
page is not dirty. ● if the page was already written to
disk earlier, no need to re-copy to disk
SPL/2010 21SPL/2010
Page Replacement Policy● The operating system must decide
which page to swap out● page replacement policy: usually
relies on some kind of LRU (recently used list)
SPL/2010 22SPL/2010