type
status
date
slug
summary
tags
category
icon
password
Below are notes from Architectural and Operating System Support for Virtual Memory.
Purpose of the book
- state of the art in Virtual Memory design
- open research and development questions that will guide the evolution of the VM in coming years
- architecture heterogeneity, so-called "big data"
- virtualization
1. Why Virtual Memory is Used
Virtual Memory
- VM abstractions allows code to be written as if it has total unrestricted control of the entire available memory range, no need consider memory usage of other programs concurrently running
- programs is portable when physical resources is changed (dynamic change of utilization or static change (e.g. different machine))
- e.g. no need to know RAM chips configuration/capacity
- VM provides protection and isolation
- prevents buggy/malicious code to touch memory of other running program where they have no access
- VM improves efficiency
- programs can undersubscribe(use less memory than they allocate) or oversubscribe(allocate more memory than is physically available)
- no requirement that virtual and physical memory be the same size
- Other memory management tasks
- efficient arrangement of memory regions(less inaccessible or wasted resources)
- handle oversubscribe by swapping certain memory regions from memory to disk drive
- some performance issue can be mitigated by smart VM implementation
- Migrate memory from one physical address to another (recently emerging scenario)
- move memory from one socket to another, from type of physical memory into another (e.g. DRAM to non-volatile memory), from one device to another (e.g. CPU to GPU), or defragment memory regions within one physical memory block
2. Issues with Modern Virtual Memory
2.1 Performance
Memory access traditionally make up 1/3 of the instructions in typical program. Unless cache is VIVT, every load/store passes VM subsystem.
Today, VM cost 5-20% of runtime, or even 20%-50% in virtualized environment.
Program working sets are larger and large, the hardware structures and operating system algorithms that have been used to efficiently implement VM in the past are struggling to keep up. (superpages and TLB prefetching can help performance)
2.2 Heterogeneous architecture
GPUs and DSPs becomes more tightly integrated and shares virtual address spaces with CPU user code. The trends are driving new research and development to get VM to scale up to much larger and broader environment that is had ever been used for in past decades.
Techniques such as
- migrating pages between memories and between devices
- scalable TLB synchronization algorithms
- IOMMU to allow devices to share virtual address space with the CPU
2.3 Modern VM topics that is traditional
TLB structures, sizes, organizations, allocation, replacement policies are increasing important as the workloads data set is increasing. (these topics is explored in Chapter 3-5)
2.4 Correctness
VM need correct hardware and software cooperation. Read-word VM implementations routinely suffer from bugs in both the hardware and OS layers. Tools and methodologies that allow for disciplined formal reasoning of VM correctness is more pressing to go forward. (these topics is explored in Chapter 6)
2.5 Fundamental question
VM was conceived when memory was scarce, as systems embrace increasing amount of memory, does it still make sense to use VM ?
If till use VM, then
- paging and segmentation
- appropriate page sizes
- page migration mechanism and policies among sockets and among emerging die-stacked and non-volatile memory
- right VM support for emerging hardware accelerators beyond GPUs
(these topics is explored in Chapter 7-9)