Memory Management Abstractions

1
Memory Management Abstractions

• Still Room For Innovation
• Myles Watson

2
Introduction In This Talk I Will

• Beat around the bush
• Cover seven research areas
• Focus on one paper from each area
• Expose the hole in the landscape

3
What Im Proposing

• Adding a very large memory device to computers
• Controlling cost by using disk
• Improving performance by intelligently monitoring
  memory usage

4
Seven topics

• Virtual Memory
• Page Management
• Single Level Stores
• Single-Address Space Operating Systems
• Persistence
• Main-Memory Databases
• DRAM Considerations

5
Virtual Memory

• Atlas
• Dennings Survey
• Multics
• Pilot

6
Atlas (Fotheringham 1961)

• First implementation of virtual memory
• Page frames introduced
• Pages of data are resident in core or on a paging
  drum
• Supervisor handles paging
• Programmers can use convenient addresses

7
Virtual Memory Take Away

• Virtual memory
• Simplifies programming
• Reduces bugs by removing ad hoc memory management

8
Page Management

• Application-Controlled Demand Paging for
  Out-of-Core Visualization
• Reducing Cache Misses Using Hardware and Software
  Page Placement
• Dynamic Tracking of Page Miss Ratio Curves for
  Memory Management
• Power Aware Page Allocation

9
Dynamic Tracking of Page Miss Ratio Curves for
Memory Management

• Paging decisions are poor
• Due to lack of information
• Track page miss ratio curves to improve them
• Hardware solution (simulated)
• Improves energydelay 27-58
• Software solution (Linux modifications)
• 7-10 overhead 63 reduction in faults
• Improved response time by factor of 5.8

10
Page Management Take Away

• More information can lead to better decisions
• Room for significant improvements

11
Single-Level Stores

• Inside the AS/400
• 801 Storage Architecture and Programming
• Design Evolution of the EROS Single-Level Store
• Smooth and Efficient Integration of
  High-Availability in a Parallel Single Level
  Store System

12
Inside the AS/400

• AS/400 is an IBM small-business machine
• Designed to be robust, secure, abstract
• The operating system runs in a VM
• Portable
• Programs are compiled when loaded

13
Single-Level Store Take Away

• Single-level stores have
• Been implemented in operating systems and in
  virtual machines
• Been successful for databases and business
  workloads
• Simplified programming

14
Single Address Space Operating Systems (SASOS)

• Architectural Support for Single Address Space
  Operating Systems
• Using a Single Address Space Operating System to
  Support Modern Cluster Computing

15
Architectural Support for Single Address Space
Operating Systems

• SASOS are based on large address spaces
• Never re-use addresses
• Simplifies sharing, complicates protection
• Need virtually addressed caches
• Need protection look aside buffers

16
SASOS Take Away

• SASOS are a not what we are proposing to do

17
Persistence

• Persistent Memory A Storage Architecture for
  Object-Oriented Database Systems
• Do You Still Use a Database?
• eNVy A Non-Volatile, Main Memory Storage System
• Non-Volatile Memory for Fast, Reliable File
  Systems

18
Persistence Continued

• Quickstore High Performance Mapped Object Store
• Architectures for Persistence

19
Persistent Memory A Storage Architecture for
Object-Oriented Database Systems

• Traditional databases are inflexible
• Extensions are slow kludges
• Persistent memory allows fast, elegant solutions
• Checkpoints maintain persistence

20
Persistence Take Away

• Transparent persistence
• Simplifies programming
• Increases performance

21
Main-Memory Databases

• Main-Memory Database Systems an Overview
• Monet An Impressionist Sketch of an Advanced
  Database System
• Xmas an Extensible Main-Memory Storage System
• The Architecture of the Dalí Main-Memory Storage
  Manager

22
Monet An Impressionist Sketch of an Advanced
Database System

• The hot sets of many databases will fit in memory
• Monet assumes that is the common case
• Monet can be extended to use virtual memory for
  graceful degradation with paging

23
Main-Memory Databases Take Away

• There is significant overhead to disk storage
• Databases can be optimized for main-memory

24
DRAM Considerations and Controllers

• Concurrency, Latency, or System Overhead Which
  Has the Largest Impact on Uniprocessor
  DRAM-system Performance?
• Memory Controller Optimizations for Web Servers
• The Impulse Memory Controller

25
Concurrency, Latency, or System Overhead Which
Has the Largest Impact on Uniprocessor
DRAM-system Performance?

• With fixed CPU and DRAM timings
• Concurrency and system overhead have the largest
  impacts on performance

26
DRAM Take Away

• Increased latencies can be traded for
• More concurrency
• Lower system overhead

27
Summary and Conclusions

• Hardware single-level store
• Combine DRAM and disk
• Collect and use more memory usage information
• Enable persistence
• Simplify operating systems and applications

28
Seven Topics Intersecting

• Another level of virtual memory
• Improved page management
• Single level store in hardware
• Could support a SASOS not a SASOS
• Enables inexpensive persistence
• Improves main-memory databases
• DRAM Considerations trade some latency for
  efficiency and simplicity

29
Questions?