CS 3204 Operating Systems Godmar Back Lecture 15.

Slides:



Advertisements
Similar presentations
CS 4284 Systems Capstone Godmar Back Virtual Memory – Paging Techniques.
Advertisements

EECS 470 Virtual Memory Lecture 15. Why Use Virtual Memory? Decouples size of physical memory from programmer visible virtual memory Provides a convenient.
May 7, A Real Problem  What if you wanted to run a program that needs more memory than you have?
Computer Organization CS224 Fall 2012 Lesson 44. Virtual Memory  Use main memory as a “cache” for secondary (disk) storage l Managed jointly by CPU hardware.
Lecture 34: Chapter 5 Today’s topic –Virtual Memories 1.
1 A Real Problem  What if you wanted to run a program that needs more memory than you have?
CSE 490/590, Spring 2011 CSE 490/590 Computer Architecture Virtual Memory I Steve Ko Computer Sciences and Engineering University at Buffalo.
CS 153 Design of Operating Systems Spring 2015
The Memory Hierarchy (Lectures #24) ECE 445 – Computer Organization The slides included herein were taken from the materials accompanying Computer Organization.
CS 333 Introduction to Operating Systems Class 12 - Virtual Memory (2) Jonathan Walpole Computer Science Portland State University.
CS 333 Introduction to Operating Systems Class 12 - Virtual Memory (2) Jonathan Walpole Computer Science Portland State University.
S.1 Review: The Memory Hierarchy Increasing distance from the processor in access time L1$ L2$ Main Memory Secondary Memory Processor (Relative) size of.
Recap. The Memory Hierarchy Increasing distance from the processor in access time L1$ L2$ Main Memory Secondary Memory Processor (Relative) size of the.
Translation Buffers (TLB’s)
CS333 Intro to Operating Systems Jonathan Walpole.
CS 3204 Operating Systems Godmar Back Lecture 11.
CS 153 Design of Operating Systems Spring 2015 Lecture 17: Paging.
CS 4284 Systems Capstone Godmar Back Virtual Memory – Page Tables.
Operating Systems ECE344 Ding Yuan Paging Lecture 8: Paging.
July 30, 2001Systems Architecture II1 Systems Architecture II (CS ) Lecture 8: Exploiting Memory Hierarchy: Virtual Memory * Jeremy R. Johnson Monday.
Lecture Topics: 11/17 Page tables TLBs Virtual memory flat page tables
Fundamentals of Programming Languages-II Subject Code: Teaching SchemeExamination Scheme Theory: 1 Hr./WeekOnline Examination: 50 Marks Practical:
Virtual Memory Part 1 Li-Shiuan Peh Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology May 2, 2012L22-1
1 Some Real Problem  What if a program needs more memory than the machine has? —even if individual programs fit in memory, how can we run multiple programs?
Virtual Memory Additional Slides Slide Source: Topics Address translation Accelerating translation with TLBs class12.ppt.
Review °Apply Principle of Locality Recursively °Manage memory to disk? Treat as cache Included protection as bonus, now critical Use Page Table of mappings.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Demand Paging.
CS 3204 Operating Systems Godmar Back Lecture 17.
CS2100 Computer Organisation Virtual Memory – Own reading only (AY2015/6) Semester 1.
Virtual Memory Ch. 8 & 9 Silberschatz Operating Systems Book.
Pintos project 3: Virtual Memory Management
CS 3204 Operating Systems Godmar Back Lecture 16.
Constructive Computer Architecture Virtual Memory: From Address Translation to Demand Paging Arvind Computer Science & Artificial Intelligence Lab. Massachusetts.
W4118 Operating Systems Instructor: Junfeng Yang.
Virtual Memory – Paging Techniques
Translation Lookaside Buffer
Lecture 11 Virtual Memory
A Real Problem What if you wanted to run a program that needs more memory than you have? September 11, 2018.
Virtual Memory User memory model so far:
From Address Translation to Demand Paging
From Address Translation to Demand Paging
Today How was the midterm review? Lab4 due today.
Virtual Memory – Page Tables
Some Real Problem What if a program needs more memory than the machine has? even if individual programs fit in memory, how can we run multiple programs?
CS 5204 Operating Systems Linking and Loading Godmar Back.
Memory Hierarchy Virtual Memory, Address Translation
CSE 153 Design of Operating Systems Winter 2018
From Address Translation to Demand Paging
Translation Lookaside Buffer
CS 5204 Operating Systems Lecture 10
Morgan Kaufmann Publishers Memory Hierarchy: Virtual Memory
CSE 451: Operating Systems Autumn 2005 Memory Management
Translation Buffers (TLB’s)
CSE 451: Operating Systems Autumn 2003 Lecture 10 Paging & TLBs
CSE451 Virtual Memory Paging Autumn 2002
Virtual Memory Prof. Eric Rotenberg
CSE 451: Operating Systems Autumn 2003 Lecture 9 Memory Management
Translation Buffers (TLB’s)
CSC3050 – Computer Architecture
CSE 451: Operating Systems Autumn 2003 Lecture 10 Paging & TLBs
CSE 451: Operating Systems Autumn 2003 Lecture 9 Memory Management
Lecture 8: Efficient Address Translation
Translation Lookaside Buffers
Paging and Segmentation
CSE 451: Operating Systems Lecture 10 Paging & TLBs
CS703 - Advanced Operating Systems
CSE 153 Design of Operating Systems Winter 2019
Translation Buffers (TLBs)
Virtual Memory.
Cache writes and examples
Presentation transcript:

CS 3204 Operating Systems Godmar Back Lecture 15

10/22/2015CS 3204 Fall Announcements Project 2 due Oct 20, 11:59pm –See forum for additional office hours Reminder: need to pass 90% of tests of project 2 by the end of the semester to pass the class –That’s all tests (except for possibly multi-doom) –P2 score will depend on what you pass by the deadline. –P2 is a prerequisite for projects 3 and 4 – if you can’t get all tests to pass by submission deadline, fix them quickly

Virtual Memory

10/22/2015CS 3204 Fall Virtual Memory Is not a “kind” of memory Is a technique that combines one or more of the following concepts: –Address translation (always) –Paging (not always) –Protection (not always, but usually) Can make storage that isn’t physical random access memory appear as though it were

10/22/2015CS 3204 Fall Goals for Virtual Memory Virtualization –Maintain illusion that each process has entire memory to itself –Allow processes access to more memory than is really in the machine (or: sum of all memory used by all processes > physical memory) Protection –make sure there’s no way for one process to access another process’s data

10/22/2015CS 3204 Fall Context Switching Process 1 Process 2 Kernel user mode kernel mode P1 startsP2 startsP1 exitsP2 exits

10/22/2015CS 3204 Fall ustack (1) Process 1 Active in user mode kernel ucode (1) kcode kdata kbss kheap 0 C C FFFFFFFF 3 GB 1 GB used free user (1) udata (1) user (1) user (2) access possible in user mode P1

10/22/2015CS 3204 Fall ustack (1) Process 1 Active in kernel mode kernel ucode (1) kcode kdata kbss kheap 0 C C FFFFFFFF 3 GB 1 GB used free user (1) udata (1) user (1) user (2) access possible in user mode access requires kernel mode P1

10/22/2015CS 3204 Fall ustack (2) Process 2 Active in kernel mode kernel user (1) ucode (2) kcode kdata kbss kheap 0 C C FFFFFFFF 3 GB 1 GB used free user (2) udata (2) user (2) access possible in user mode access requires kernel mode P2

10/22/2015CS 3204 Fall ustack (2) Process 2 Active in user mode kernel user (1) ucode (2) kcode kdata kbss kheap 0 C C FFFFFFFF 3 GB 1 GB used free user (2) udata (2) user (2) access possible in user mode P2

10/22/2015CS 3204 Fall Page Tables How are the arrows in previous pictures represented? –Page Table: mathematical function “Trans” Typically (though not on all architectures) have –Trans(p i, v a, user, *) = Trans(p i, v a, kernel, *) OR Trans(p i, v a, user, *) = INVALID –E.g., user virtual addresses can be accessed in kernel mode Trans: { Process Ids }  { Virtual Addresses }  { user, kernel }   ({ read, write, execute })  { Physical Addresses }  { INVALID }

10/22/2015CS 3204 Fall Sharing Variations We get user-level sharing between processes p 1 and p 2 if –Trans(p 1, v a, user, *) = Trans(p 2, v a, user, *) Shared physical address doesn’t need to be mapped at same virtual address, could be mapped at v a in p 1 and v b in p 2 : –Trans(p 1, v a, user, *) = Trans(p 2, v b, user, *) Can also map with different permissions: say p 1 can read & write, p 2 can only read –Trans(p 1, v a, user, {read, write}) = Trans(p 2, v b, user, {read}) In Pintos (and many OS) the kernel virtual address space is shared among all processes & mapped at the same address: –Trans(p i, v a, kernel, *) = Trans(p k, v a, kernel, *) for all processes p i and p k and v a in [0xC , 0xFFFFFFFF]

Per-Process Page Tables Can either keep track of all mappings in a single table, or can split information between tables –one for each process –mathematically: a projection onto a single process For each process pi define a function PTransi as –PTransi (va, *, *) = Trans(pi, va, user, *) Implementation: associate representation of this function with PCB, e.g., per-process hash table –Entries are called “page table entries” or PTEs Nice side-effect: –reduced need for synchronization if every process only adds/removes entries to its own page table 10/22/2015CS 3204 Fall

10/22/2015CS 3204 Fall Per-Process Page Tables (2) Common misconception –“User processes use ‘user page table’ and kernel uses ‘kernel page table’” – as if those were two tables Not so (on x86): mode switch (interrupt, system call) does not change the page table that is used –It only “activates” those entries that require kernel mode within the current process’s page table Consequence: kernel code also cannot access user addresses that aren’t mapped

10/22/2015CS 3204 Fall Non-Resident Pages When implementing virtual memory, some of a process’s pages may be swapped out –Or may not yet have been faulted in Need to record that in page table: Trans (with paging): { Process Ids }  { Virtual Addresses }  { user, kernel }   ({ read, write, execute })  { Physical Addresses }  { INVALID }  { Some Location On Disk }

10/22/2015CS 3204 Fall Implementing Page Tables Many, many variations possible Done in combination of hardware & software –Hardware part: dictated by architecture –Software part: up to OS designer Machine-dependent layer that implements architectural constraints (what hardware expects) Machine-independent layer that manages page tables Must understand how TLB works first

10/22/2015CS 3204 Fall Page Tables Function & TLB For each combination (process id, virtual_addr, mode, type of access) must decide –If access is permitted –If permitted: if page is resident, use physical address if page is non-resident, page table has information on how to get the page in memory CPU uses TLB for actual translation – page table feeds the TLB on a TLB miss Trans (with paging): { Process Ids }  { Virtual Addresses }  { user, kernel }  { read, write, execute }  { Physical Addresses }  { INVALID }  { Some Location On Disk }

10/22/2015CS 3204 Fall TLB

10/22/2015CS 3204 Fall TLB: Translation Look-Aside Buffer Virtual-to-physical translation is part of every instruction (why not only load/store instructions?) –Thus must execute at CPU pipeline speed TLB caches a number of translations in fast, fully-associative memory –typical: 95% hit rate (locality of reference principle) 0xC x PermVPNPPN RWX K0xC00000x00000 RWX K0xC00010x00001 R-X K0xC00020x00002 R-- K0xC00030x00003 ……… TLB VPN: Virtual Page Number PPN: Physical Page Number Offset

10/22/2015CS 3204 Fall TLB Management Note: on previous slide example, TLB entries did not have a process id –As is true for x86 Then: if process changes, some or all TLB entries may become invalid –X86: flush entire TLB on process switch (refilling adds to cost!) Some architectures store process id in TLB entry (MIPS) –Flushing (some) entries only necessary when process id reused

10/22/2015CS 3204 Fall Address Translation & TLB Virtual Address TLB Lookup Check Permissions Physical Address Page Fault Exception “Protection Fault” Page Table Walk Page Fault Exception “Page Not Present” TLB Reload Terminate Process misshit restart instruction page presentelse okdenied Load Page done in hardware done in OS software done in software or hardware machine-dependent machine-independent logic

10/22/2015CS 3204 Fall TLB Reloaded TLB small: typically only caches 64-2,048 entries –What happens on a miss? – must consult (“walk”) page table – TLB Reload or Refill TLB Reload in software (MIPS) –Via TLB miss handlers – OS designer can pick any page table layout – page table is only read & written by OS TLB Reload in hardware (x86) –Hardware & software must agree on page table layout inasmuch as TLB miss handling is concerned – page table is read by CPU, written by OS Some architectures allow either (PPC)

10/22/2015CS 3204 Fall Page Tables vs TLB Consistency No matter which method is used, OS must ensure that TLB & page tables are consistent –On multiprocessor, this may require “TLB shootdown” For software-reloaded TLB: relatively easy –TLB will only contain what OS handlers place into it For hardware-reloaded TLB: two choices –Use same data structures for page table walk & page loading (hardware designers reserved bits for OS’s use in page table) –Use a layer on top (facilitates machine-independent implementation) – this is the recommended approach for Pintos Project 3 In this case, must update actual page table (on x86: “page directory”) that is consulted by MMU during page table walk Code is already written for you in pagedir.c

10/22/2015CS 3204 Fall Hardware/Software Split in Pintos CPU cr3 Machine-dependent Layer: pagedir.c code Machine-dependent Layer: pagedir.c code Machine-independent Layer: your code & data structures “supplemental page table” Machine-independent Layer: your code & data structures “supplemental page table”