Virtual Memory 2: demand paging

Transcription

1 Virtual Memory : demand paging also: anatomy of a process Guillaume Salagnac Insa-Lyon IST Semester Fall 8

2 Reminder: OS duties CPU CPU cache (SRAM) main memory (DRAM) fast storage (SSD) large storage (disk) Virtual Memory means: hiding the actual location of data during execution placing data and moving it around to improve performance doing so for several processes running simultaneously /9

3 Virtual memory: principle VA=VPN.PO CPU VPN VAS MMU/TLB VPN PPN Ø Ø PT PA=PPN.PO PPN PAS Address space virtualization: CPU only works with Virtual Addresses MMU/TLB translates every request into a Physical Address virtual-to-physical mapping info stored in the Page Table one Virtual Address Space (i.e. one PT) for each process /9

4 4/9 Outline. Virtual Memory for runtime performance: demand paging. Virtual Memory for multiprogramming: page sharing. Virtual Memory for isolation and protection 4. Anatomy of a Virtual Address Space

5 VM for speed: demand paging and swapping Remember: we use DRAM as a cache for the disk Demand Paging: working principle allocate all virtual pages of all processes on the disk only load a page to RAM when it is actually required Possible states for each virtual page: Unmapped = page doesn t exist no data associated with page (neither in memory nor on disk) AKA unallocated Present = page exists and is currently copied in memory data can be access by CPU AKA mapped, loaded, cached, swapped-in Unloaded = allocated on disk but currently not in memory AKA uncached, swapped-out note: page state recorded in PTE 5/9

6 Swapping data between memory and disk Question: what happens if CPU tries to access an unloaded page? CPU DRAM Disk VAS Ø Ø PAS VPN PPN metadata present present Ø unallocated Ø unloaded to disk sector n o 8 6/9

7 7/9 Swapping data between memory and disk From the MMU viewpoint: page in memory = access is possible = PTE is valid page not in memory = access not possible = PTE is invalid unallocated or unloaded implementation: boolean flag in PTE known as the valid bit When a program tries to access an invalid page: MMU raises a software interrupt (trap) CPU jumps in the kernel and executes associated ISR if page is unallocated non-recoverable error kernel kills the process (segmentation fault) if page is unloaded process is not guilty! kernel handles page fault by loading data in memory

8 8/9 Page fault handling. CPU requests a certain virtual address. MMU looks VA up in PT but finds a PTE with valid=false. MMU sends an interrupt request with offending instruction and address 4. CPU switches to supervisor mode and jumps to ISR 5. OS reads page table of current process check that virtual page does exist (i.e. is allocated) 6. OS find a free physical page (by looking in the frame table) sometimes we must swap out a page to make space 7. OS swaps in the required page from disk disk access = I/O burst context switch to keep CPU busy 8. when page loaded: OS updates PTE to reflect new mapping 9. OS marks original process as ready still transparent for application programmer

9 Demand paging: summary Idea: use DRAM as a cache for the disk complicated interaction between software and hardware MMU detects accesses to unloaded pages: page fault OS deals with loading/unloading to disk: swapping invisible from userland CPU kept busy via context switching Average access time to main memory: AMAT = page hit time + (page fault rate page fault penalty) page hit time DRAM latency 5 ns page fault penalty disk latency 5 ms system performance is very sensitive to page fault rate 9/9

10 /9 Outline. Virtual Memory for runtime performance: demand paging. Virtual Memory for multiprogramming: page sharing. Virtual Memory for isolation and protection 4. Anatomy of a Virtual Address Space

11 Reminder: OS duties CPU CPU cache (SRAM) main memory (DRAM) fast storage (SSD) large storage (disk) Virtual Memory means: hiding the actual location of data during execution placing data and moving it around to improve performance doing so for several processes running simultaneously /9

12 VM for multiprogramming: process isolation Idea: each process gets an individual virtual address space OS maintains one page table per process Page Table Page Table Ø Ø Ø Ø VAS PAS VAS Remarks: RAM allocated to the most useful virtual pages MMU reconfigured at each context switch flush the TLB i.e. forget all PTEs of previous process take as new reference the PT of the new process /9

13 VM for multiprogramming: shared memory Idea: enable several processes to communicate one physical page can be mapped into several VASes Page Table Page Table Ø Ø Ø Ø VAS PAS VAS Remarks: feature accessible through kernel API: mmap() syscall shared page typically placed at the same VA why? /9

14 4/9 Outline. Virtual Memory for runtime performance: demand paging. Virtual Memory for multiprogramming: page sharing. Virtual Memory for isolation and protection 4. Anatomy of a Virtual Address Space

15 5/9 VM for security: kernel protection Idea: each PTE contain some permission information e.g: read-only, non-executable, kernel-only... if PTE is valid MMU also checks for permissions Page Table Page Table { } Ø user space user space Ø { } kernel space kernel space VAS PAS VAS Remarks: kernel typically mapped (though protected) in every VAS in general, located above userspace in the VAS e.g. Linux x86: GB=user space, GB 4GB=kernel not all pages allocated!

16 VM for security: MMIO protection Idea: physical addresses lead to DRAM and peripherals Memory-mapped input/output typically: DRAM allocated to userland MMIO restricted to kernel easy to enforce using paging Note: the MMU is a peripheral too 6/9

17 Virtual memory: summary Under the responsibility of the kernel reconfigure the MMU/TLB at every context switch one process = one page table handle page faults carry out all swapping operations between RAM and disk allocate memory pages for processes e.g. via the mmap() syscall before: VAS mmap(...) after: VAS 7/9

18 8/9 Outline. Virtual Memory for runtime performance: demand paging. Virtual Memory for multiprogramming: page sharing. Virtual Memory for isolation and protection 4. Anatomy of a Virtual Address Space Static allocation:.text and.data sections Stack allocation of local variables Heap allocation of dynamic data structures

19 Virtual memory: principle VA=VPN.PO CPU VPN VAS MMU/TLB VPN PPN Ø Ø PT PA=PPN.PO PPN PAS Address space virtualization: CPU only works with Virtual Addresses MMU/TLB translates every request into a Physical Address virtual-to-physical mapping info stored in the Page Table one Virtual Address Space (i.e. one PT) for each process 9/9

20 Anatomy of a process address space VPN To launch a new program: create a new PCB and a new PT copy the executable in memory PCB.PC := address of main() 4 PCB.state := ready 5 append PCB to the ready queue X Virtual Address Space one executable = several sections.text = program instructions.data = global variables.heap = dynamic allocation.stack = local variables (+ calls) show contents of an executable file: objdump -h./prog.elf objdump -d./prog.elf /9

21 Static allocation of instructions and global variables Static = «does not move during execution» location decided once, before execution begins size decided once, before execution begins source code: int i,n,r; factorial() { i = ; } while(n>) { i = i*n; n = n-; } r = i; machine code: 848a7: aa: c7 5 c b: 848b4: eb 848b6: 8b 5 c bc: a c: f af c 848c4: a c c9: a ce: 8 e8 848d: a d6: a db: 85 c 848dd: 7f d7 848df: a c e4: a e9:... /9

22 Static allocation of instructions and global variables Static = «does not move during execution» location decided once, before execution begins size decided once, before execution begins source code: int i,n,r; factorial() { i = ; } while(n>) { i = i*n; n = n-; } r = i; disassembled machine code: 848a7: aa: movl $x, x8496c 848b: 848b4: jmp x848d6 848b6: mov x8496c,%edx 848bc: mov x8496,%eax 848c: imul %edx,%eax 848c4: mov %eax, x8496c 848c9: mov x8496,%eax 848ce: sub $x,%eax 848d: mov %eax, x d6: mov x8496,%eax 848db: test %eax,%eax 848dd: jg x848b6 848df: mov x8496c,%eax 848e4: mov %eax, x e9:... /9

23 Dynamic allocation in the.stack section Problem: what if the size and/or quantity of variables is unknown before execution? int f(int n) { if(n<=) return ; int a=f(n-); int b=f(n-); return a+b; } Solution: use an unbounded data structure i.e. a stack Remarks: approach used in 99% of programming languages AKA execution stack, program stack, control stack, run-time stack, machine stack, call stack, or just the stack one function activation = one portion of the stack local variables, function arguments, return address... dedicated CPU instructions: PUSH, POP, CALL, RET top of stack tracked by Stack Pointer register SP memory beyond SP not considered significant /9

24 The execution stack: remarks CPU SP Definition: area dedicated to dynamic allocation allocated and released Last-In First-Out contents: local variables, return addresses... managed by the compiler top of stack pointed by SP register Advantages easy to use for the programmer maps nicely to features of high-level languages efficient at runtime using register-indirect addressing mode e.g. LOAD [SP] automatic stack growth implemented by OS Limitations LIFO: not suitable for certain data structures /9

25 Dynamic allocation at runtime AKA heap allocation Idea: allow for arbitrary allocations/deallocations during execution User interface malloc(size) size search the heap for a large-enough free zone, return its address (or return an error if unable to find one) free(address) notify the allocator that a previously allocated block is no longer needed and can be reused for later allocations Advantages total flexibility for the programmer compatible with all kinds of data structures Drawbacks total flexibility for the programmer complex implementation allocation can become slow 4/9

26 Heap allocation vs allocation of new VM pages Problem: how to implement malloc() and free()? Bad idea: forward all allocation requests to the kernel e.g. via the mmap() and munmap() syscalls before: after: mmap(...) VAS VAS Drawbacks cannot allocate half a page wasted space AKA fragmentation frequent system calls bad performance Solution: implement the memory allocator in userspace recycle freed block within the same process when possible only when heap is full request new pages from kernel 5/9

27 } } } } } } } Heap allocation: remarks Why it is hard: cannot split a request: allocated zone must be contiguous cannot move a block once allocated: app has pointers to it if several blocks are possible: which one to choose? if chosen free block is too large: should we split it? too many free blocks allocation becomes slow free blocks too small unable to use them for allocation Data structure: list of free blocks AKA freelist Occ. Occupied Free Occ. Free Occ. Free Occ. Occupied Example: where to allocate a block of size? 5?? 6/9

28 Anatomy of a process: summary VPN X Virtual Address Space one VAS = several sections.text = program instructions (static) initialized from executable file VM flags: read-only, executable.data = global variables (static) initialized from executable file VM flags: read-write, non-executable.heap = dynamic allocation userspace malloc()/free() API mmap() to request new pages when full.stack = local variables (+ calls) accessed via PUSH/POP instructions Last In First Out allocation 7/9

29 8/9 Outline. Virtual Memory for runtime performance: demand paging. Virtual Memory for multiprogramming: page sharing. Virtual Memory for isolation and protection 4. Anatomy of a Virtual Address Space Static allocation:.text and.data sections Stack allocation of local variables Heap allocation of dynamic data structures

30 Summary Virtual memory via paging dissociate logical addresses from physical addresses managed in software (kernel) + hardware (MMU/TLB) Demand paging swap memory pages between DRAM and disk page faults detected by MMU, handled by OS disk is slow faults must remain unfrequent Memory allocation static (code, globals) vs dynamic allocation execution stack for local variables heap allocation with malloc()/free() 9/9