Learning to Play Well With Others

Size: px

Start display at page:

Download "Learning to Play Well With Others"

Janel Little
5 years ago
Views:

1 Virtual Memory 1

2 Learning to Play Well With Others (Physical) Memory 0x10000 (64KB) Stack Heap 0x00000

3 Learning to Play Well With Others malloc(0x20000) (Physical) Memory 0x10000 (64KB) Stack Heap 0x00000

4 Learning to Play Well With Others malloc(0x20000) (Physical) Memory 0x10000 (64KB) Stack Heap 0x00000

5 Learning to Play Well With Others (Physical) Memory 0x10000 (64KB) Stack Heap 0x00000

6 Learning to Play Well With Others (Physical) Memory 0x10000 (64KB) Stack Heap 0x00000

7 Learning to Play Well With Others (Physical) Memory 0x10000 (64KB) Stack Heap 0x00000

8 Learning to Play Well With Others (Physical) Memory 0x10000 (64KB) Stack Heap 0x00000

9 Learning to Play Well With Others Virtual Memory 0x10000 (64KB) Stack Heap 0x00000 Virtual Memory 0x10000 (64KB) Stack Heap 0x00000

10 Learning to Play Well With Others Virtual Memory 0x10000 (64KB) Stack Physical Memory Heap 0x x10000 (64KB) Virtual Memory 0x10000 (64KB) Stack 0x00000 Heap 0x00000

11 Learning to Play Well With Others Virtual Memory 0x10000 (64KB) Stack Physical Memory Heap 0x x10000 (64KB) Virtual Memory 0x10000 (64KB) Stack 0x00000 Heap 0x00000

Learning to Play Well With Others Virtual Memory 0x400000 (4MB) Stack Physical Memory Heap

12 Learning to Play Well With Others Virtual Memory 0x (4MB) Stack Physical Memory Heap 0x x10000 (64KB) Virtual Memory 0xF (240MB) Stack 0x00000 Disk (GBs) Heap 0x00000

13 Mapping Virtual-to-physical mapping Virtual --> virtual address space physical --> physical address space We will break both address spaces up into pages Typically 4KB in size, although sometimes large Use a page table to map between virtual pages and physical pages. The processor generates virtual addresses They are translated via address translation into physical addresses. 6

14 Implementing Virtual Memory (or whatever) Stack We need to keep track of this mapping Heap 0 0 Virtual Address Space Physical Address Space

15 The Mapping Process Virtual address (32 bits) Virtual Page Number Page Offset (log(page size)) Virtual-to-physical map Physical Page Number Page Offset (log(page size)) Physical address (32 bits) 8

16 Two Problems With VM How do we store the map compactly? How do we translation quickly? 9

17 How Big is the map? 32 bit address space: 4GB of virtual addresses 1MPages Each entry is 4 bytes (a 32 bit physical address) 4MB of map 64 bit address space 16 exabytes of virtual address space 4PetaPages Entry is 8 bytes 64PB of map 10

18 Shrinking the map Only store the entries that matter (i.e.,. enough for your physical address space) 64GB on a 64bit machine 16M pages, 128MB of map This is still pretty big. Representing the map is now hard The OS allocates stuff all over the place. For security, convenience, or caching optimizations How do you represent this sparse map. 11

19 Hierarchical Page Tables Break the virtual page number into several pieces If each piece has N bits, build an 2 N -ary tree Only store the part of the tree that contain valid pages To do translation, walk down the tree using the pieces to select with child to visit. 12

20 Hierarchical Page Table Virtual Address p1 p2 offset 0 10-bit L1 index Root of the Current Page Table 10-bit L2 index p2 offset p1 (Processor Register) Level 1 Page Table Level 2 Page Tables Parts of the map that exist Parts that don t Data Pages

21 Making Translation Fast Address translation has to happen for every memory access This potentially puts it squarely on the critical for memory operation (which are already slow) 14

22 Solution 1 : Use the Page Table We could walk the page table on every memory access Result: every load or store requires an additional 3-4 loads to walk the page table. Unacceptable performance hit. 15

23 Solution 2: TLBs We have a large pile of data (i.e., the page table) and we want to access it very quickly (i.e., in one clock cycle) So, build a cache for the page mapping, but call it a translation lookaside buffer or TLB 16

24 TLBs TLBs are small (maybe 128 entries), highlyassociative (often fully-associative) caches for page table entries. This raises the possibility of a TLB miss, which can be expensive To make them cheaper, there are hardware page table walkers -- specialized state machines that can load page table entries into the TLB without OS intervention This means that the page table format is now part of the big-a architecture. Typically, the OS can disable the walker and implement its own format. 17

25 Solution 3: Defer translating Accesses If we translate before we go to the cache, we have a physically cache, since cache works on physical addresses. Critical path = TLB access time + Cache access time CPU VA TLB Physical Cache PA Primary Memory Alternately, we could translate after the cache Translation is only required on a miss. This is a virtual cache VA CPU Virtual Cache TLB PA Primary Memory 18

26 The Danger Of Virtual Caches (1) Process A is running. It issues a memory request to address 0x10000 It is a miss, and is brought into the virtual cache A context switch occurs Process B starts running. It issues a request to 0x10000 Will B get the right data? 19

27 The Danger Of Virtual Caches (1) Process A is running. It issues a memory request to address 0x10000 It is a miss, and is brought into the virtual cache A context switch occurs Process B starts running. It issues a request to 0x10000 Will B get the right data? No! We must flush virtual caches on a context switch. 19

28 The Danger Of Virtual Caches (2) There is no rule that says that each virtual address maps to a different physical address. When this occurs, it is called aliasing Example: An alias exists in the cache 0x1000 Page Table 0xfff0000 Address 0x1000 Cache Data A 0x2000 0xfff0000 0x2000 A Store B to 0x1000 Page Table 0x1000 0xfff0000 Cache Address Data 0x1000 B 0x2000 0xfff0000 Now, a load from 0x2000 will return the wrong value 0x2000 A 20

29 The Danger Of Virtual Caches (2) There is no rule that says that each virtual address maps to a different physical address. Copy on write: char * A char * A Virtual address space Physical address space Virtual address space Physical address space My Big Data By Big Empty Buffer memcpy(a, B, ) My Big Data char * B; char * B; My Empty Buffer My Big Data memcpy(a, B, ) Unwriteable copy My Big Data The initial copy is free, and the OS will catch attempts to write to the copy, and do the actual copy lazily. There are also system calls that let you do this arbitrarily. 21

30 The Danger Of Virtual Caches (2) There is no rule that says that each virtual address maps to a different physical address. Copy on write: char * A char * A Two virtual addresses pointing the same physical address Virtual address space Physical address space Virtual address space Physical address space My Big Data By Big Empty Buffer memcpy(a, B, ) My Big Data char * B; char * B; My Empty Buffer My Big Data memcpy(a, B, ) Unwriteable copy My Big Data The initial copy is free, and the OS will catch attempts to write to the copy, and do the actual copy lazily. There are also system calls that let you do this arbitrarily. 21

31 Avoiding Aliases If the system has virtual caches, the operating system must prevent alias from occurring. This means that any addresses that may alias must map to the same cache index. If VA1 and VA2 are aliases, VA1 mod (cache size) == VA2 mod (cache size) 22

32 Solution (4): Virtually indexed physically tagged VA key idea: page offset bits are not translated and thus can be presented to the cache immediately VPN L = C-b b Virtual Index PA TLB PPN P Page Offset Direct-map Cache Size 2 C = 2 L+b Tag hit? = Physical Tag Data Index L is available without consulting the TLB cache and TLB accesses can begin simultaneously Critical path = max(cache time, TLB time)!!! Tag comparison is made after both accesses are completed Work if Cache Size Page Size ( C P) because then all the cache inputs do not need to be translated Adapted from Arvind and Krste s MIT Course Fall 05

33 Avoiding Aliasing in Large Caches The restrictions on cache size might be too painful. In this case, we need another mechanism to avoid aliasing. 24

34 Anti-Aliasing Using Inclusive L2: MIPS R10000-style Once again, ensure the invariant that only one copy of physical address is in virtually-addressed L1 cache at any one time. The physically-addressed L2, which includes contents of L1, contains the missing virtual address bits that identify the location of the item in the L1. VA VPN a Page Offset b TLB into L2 tag Virtual Index L1 VA cache VA 1 PPN a Data VA 2 PPN a Data PA PPN Page Offset b Tag PPN = hit? Suppose VA1 and VA2 both map to PA and VA1 is already in L1, L2 (VA1 VA2) After VA2 is resolved to PA, a collision will be detected in L2 because the a 1 bits don t match. VA1 will be purged from L1 and L2, and VA2 will be loaded no aliasing! PA a 1 Data Direct-Mapped PA L2 (could be associative too, just need to check more entries) Adapted from Arvind and Krste s MIT Course Fall 05

35 In the Real World L1 caches are virtually indexed, physically tagged. Lower levels are pure physical Once you go physical, it is not possible (or desirable) to go back. 26

36 Adapted from Arvind and Krste s MIT Course Fall 05 Power PC: Hashed Page Table VPN d 80-bit VA Offset hash + PA of Slot Page Table VPN PPN VPN Base of Table Each hash table slot has 8 PTE's <VPN,PPN> that are searched sequentially If the first hash slot fails, an alternate hash function is used to look in another slot ( rehashing ) All these steps are done in hardware! Hashed Table is typically 2 to 3 times larger than the number of physical pages The full backup Page Table is a software data structure Primary Memory

37 Page table with pages on disk Virtual Address p1 p2 offset 0 10-bit L1 index Root of the Current Page Table 10-bit L2 index p2 offset p1 (Processor Register) Level 1 Page Table page in primary memory page on disk PTE of a nonexistent page Level 2 Page Tables Data Pages

38 The TLB With Disk TLB entries always point to memory, not disks 29

39 The Value of Paging Disk are really really slow. Paging is not very useful for expanding the active memory capacity of a system It s good for coarse grain context switching between apps And for dealing with memory leaks ;-) As a result, fast systems don t page. 30

40 The Future of Paging Non-volatile, solid-state memories significantly alter the trade-offs for paging. NAND-based SSDs can be between x faster than disk Is paging viable now? In what circumstances? 31

41 Other uses for VM VM provides us a mechanism for adding meta data to different regions of memory. The primary piece of meta data is the location of the data in physical ram. But we can support other bits of information as well 32

42 Other uses for VM VM provides us a mechanism for adding meta data to different regions of memory. The primary piece of meta data is the location of the data in physical ram. But we can support other bits of information as well Backing memory to disk next slide Protection Pages can be readable, writable, or executable Pages can be cachable or un-cachable Pages can be write-through or write back. Other tricks Arrays bounds checking Copy on write, etc. 33

43 Heterogeneous Memory VA space 1 VA space 2 Fast/non-dense/volatile memory Buffer cache Slower/denser/non-volatile memory Physical Address Space Really slow, really dense (Disk/SSD) VM is responsible for combining different types of data into a single, coherent interface. 34

44 Universal Memory Fast (as DRAM), dense (as flash or better), nonvolatile (as disk), reliable (as DRAM and disk), addressable (like DRAM) UM has wide-ranging systems implications Disks as fast as dram Change the file system OS overhead will now dominate accesses Potentially blurred line between volatile and non-volatile state Disk looks like DRAM. Shouldn t we access it like DRAM (i.e., using loads and stores)? Need permanent naming, protection (FS are good at this) Allocation in FS is very expensive. What are the semantics of a non-volatile data structure? Probably need language support. 35

45 Non-volatile Data Structures If non-volatile storage is byte addressable, we can apply everything we know about data structures, etc. to non-volatile data No more serialization Radically redesigned databases (Tables are built for disks) Reuse the tried-and-true programming models we use for volatile data. New problems How do you deal with power failure in this model? Transactions Do you have to trust user code? No. Use the FS to manage the namespace, the TLB to enforce protection. The common case is access. The other stuff can be slower. 36

Learning to Play Well With Others

Virtual Memory 1 Learning to Play Well With Others (Physical) Memory 0x10000 (64KB) 0x00000 Learning to Play Well With Others malloc(0x20000) (Physical) Memory 0x10000 (64KB) 0x00000 Learning to Play Well