Virtual Memory

Virtual Memory

1

Learning to Play Well With Others

malloc(0x20000)

(Physical) Memory 0x10000 (64KB) Stack

Heap 0x00000

Learning to Play Well With Others

(Physical) Memory 0x10000 (64KB) Stack

Heap 0x00000

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

0x10000 (64KB)

0x00000 Virtual Memory 0x10000 (64KB) Stack

Heap 0x00000

0x00000

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

0x10000 (64KB)

0x00000 Virtual Memory 0xF000000 (240MB) Stack

0x00000 Disk (GBs)

Heap 0x00000

Mapping mapping • Virtual-to-physical Virtual --> “virtual address space”

• •

physical --> “physical address space”

•

Typically 4KB in size, although sometimes large

will break both address spaces up into • We “pages” a “page table” to map between virtual pages • Use and physical pages. generates “virtual” addresses • TheTheyprocessor are translated via “address translation” into

•

physical addresses.

6

Implementing Virtual Memory 230 – 1 (or whatever)

232 - 1

Stack

We need to keep track of this mapping… Heap 0 Virtual Address Space

0 Physical Address Space

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

Two Problems With VM

do we store the map compactly? • How • How do we translation quickly?

9

How Big is the map? bit address space: • 324GB of virtual addresses

• 1MPages • Each entry is 4 bytes (a 32 bit physical address) • 4MB of map • address space • •6416bitexabytes of virtual address space • 4PetaPages is 8 bytes • Entry • 64PB of map 10

Shrinking the map store the entries that matter (i.e.,. enough • Only for your physical address space) on a 64bit machine • 64GB • 16M pages, 128MB of map is still pretty big. • This the map is now hard because we • Representing need a “sparse” representation.

• • •

The OS allocates stuff all over the place. For security, convenience, or caching optimizations For instance: The stack is at the “top” of memory. The heap is at the “bottom”

• How do you represent this “sparse” map?

11

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

12

Hierarchical Page Table Virtual Address 31

22 21

p1

12 11

p2

0

offset

10-bit 10-bit L1 index L2 index Root of the Current Page Table

offset p2

p1

(Processor Register)

Level 1 Page Table Level 2 Page Tables

Parts of the map that exist Parts that don’t

Data Pages Adapted from Arvind and Krste’s MIT Course 6.823 Fall 05

Making Translation Fast

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

14

“Solution 1”: Use the Page Table

could walk the page table on every memory • We access every load or store requires an additional • Result: 3-4 loads to walk the page table.

• Unacceptable performance hit. 15

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

TLBs are small (maybe 128 entries), highly• TLBs associative (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