FIRM: Fair and HIgh-PerfoRmance Memory Control for Persistent
Memory Systems MICRO-47, December 15, 2014 Jishen Zhao Onur Mutlu
Yuan Xie
Slide 2
2 New Design Opportunity with NVMs Disk/Flash Main Memory
Load/store Not persistent Storage Fopen, fread, fwrite Persistent
CPU DRAM Page faults
Slide 3
3 New Design Opportunity with NVMs Disk/Flash Main Memory
Load/store Not persistent Storage Fopen, fread, fwrite Persistent
CPU DRAM NVM Examples applications Databases, file systems,
key-value stores (In-memory data structures can immediately become
permanent) Persistent Applications Persistent Memory Load/store
Persistent STT-MRAM, PCM, ReRAM, NV-DIMM, Battery-backed DRAM,
etc.
Slide 4
4 New Design Opportunity with NVMs Disk/Flash Working Memory
Load/store Not persistent CPU DRAM NVM Persistent Memory Load/store
Persistent New use case of NVM: concurrently running two types of
applications [Kannan + HPCA14, Liu + ASPLOS14, Meza + WEED14]
Persistent Applications Main Memory Load/store Not persistent
Non-persistent Applications STT-MRAM, PCM, ReRAM, NV-DIMM,
Battery-backed DRAM, etc.
Slide 5
5 Focus of Our Work: Memory Controller Design CPU DRAM
Persistent Applications Non-persistent Applications NVM Fair and
High-Performance Memory Control MC Memory Controller Memory
requests go through the shared memory interface
Slide 6
6 Why Another Memory Control Scheme? ReadsWrites SMS [ISCA12]
PAR-BS [ISCA08] STFM [MICRO07] TCM [MICRO10] ATLAS [HPCA10] BLISS
[ICCD14] Persistent Memory FR-FCFS [ISCA00] Careful control over
writes to guarantee data persistence
Slide 7
CPU MC 7 Memory Controller DRAM NVM Memory Controller Read
Queue Write Queue Scheduler Memory Requests Determine which
requests can be sent on the memory bus to be serviced Limited
number of entries If one of them overflows, MC needs to drain it by
stalling the service of the other Memory Bus
Slide 8
8 Why conventional memory control schemes are inefficient in
persistent memory systems How to design fair and high-performance
memory control in this new scenario How to design fair and
high-performance memory control in this new scenario
Slide 9
9 Assumptions and Design Choices 1. Reads are on the critical
path of application execution 2. Applications are usually
read-intensive 1. Prioritize reads over writes (Infrequent write
queue drains) 2. Delay writes until they overflow the write queue
2. Delay writes until they overflow the write queue
AssumptionsDesign choices Conventional memory control schemes
(Application execution is read-dependent)
Slide 10
10 These assumptions no longer hold in persistent memory, which
needs to support data persistence (Data consistency when the system
suddenly crashes or loses power) Mechanisms: multiversioning and
write-order control
Slide 11
Implication of Multiversioning NVM A 11 Persistent Updates of
data structure A have multiple write requests Crash
Slide 12
Implication of Multiversioning NVM AA 12 Ver NVer N-1 - Logging
- Copy-on-write Original data [Volos+ ASPLOS11, Coburn+ ASPLOS11,
Condit+ SOSP09, Venkataraman+ FAST'11] Persistent Crash
Significantly increasing write traffic Two writes with each one
data update Significantly increasing write traffic Two writes with
each one data update
Slide 13
13 1. Reads are on the critical path of application execution
2. Applications are usually read-intensive 1. Prioritize reads over
writes Infrequent write queue drains 2. Delay writes until they
fill up the write queue 2. Delay writes until they fill up the
write queue AssumptionsDesign decisions Persistent applications are
usually write-intensive Assumptions and Design Choices
Slide 14
NVM Implication of Write-order Control 14 A Crash The two
versions are not supposed to be updated at the same time, issued in
order: A = {A 1, A 2, A 3 } A = {A 1, A 2, A 3 } Processor
Reordered by caches and MCs: A 2, A 2, A 1, A 1, A 3 A Persistent
Ver NVer N-1
