1. 18-740 Milestone 2 Enhancing Phase-Change Memory via DRAM Cache
- Brian Pak & Lincoln Roop

2. Outline Goal / Purpose of the Research Current Status Next Milestone
Implementations
Experiments and Results
Next Milestone

3. Goal / Purpose of the Research
Present the benefit of DRAM Write-Back Cache
Better Performance in Memory Read + Write
Longer Lifetime for Phase-Change Memory
Less physical writes to PCM
Prevent attacks to wear out the cells in PCM (security)
Even longer lifetime with simple wear-leveling algorithms
Present the cache replacement policy for DRAM WBC
Security-focused
Still guarantees the performance boost
Configurable parameters for the guaranteed minimum lifetime of PCM

4. Low Endurance Problem in PCM
Phase-Change Memory
Life time (in days)
perlbench: 335
gcc: 153
namd: 122
badapp: 1.6
(To damage a page, with perfect WL,
1 core, 3GHz CPU, 512MB PCM)
Memory Write Requests
~107 writes per cell
till it goes bad

5. Benefit of DRAM WBC to PCM
Phase-Change Memory
Write to PCM only when eviction in DRAM WBC
DRAM Write-back Cache
(High Endurance)
Memory Write Requests
Overall, far less write to PCM => Longer life time
Cache Policy:
Keep track of Write Density
Evict a block with the least WD

6. Current Status (1/2) Implementation
Simple wear-leveling in the simulator (row-granularity)
Change the address mapping (random) for a row when it reaches a certain threshold for the number of writes
Problem: Shuffling can break the locality of the memory contents
Attacking applications (3)
A naïve attack that simply writes to the same address repeatedly
Another naïve attack that allocates a large block of memory and writes sequentially, forcing evictions by being larger than the size of the cache
More advanced attack that uses the knowledge of cache parameters to efficiently generate evictions
Caveat: Verify the asm code generated by the compiler and ensure that the memory accesses are not optimized out, making the attack useless
Pin trace generation
Along with the traces for normal applications (from safari project), we created the traces for our attacks

7. Current Status (2/2) Experiments and Results
Generated traces for attacks look sane
When fed in the simulator, however, it reports zero pcm_writes (even with the reasonable configuration)
Suspicion: L1 Caches + DRAM Caches row buffer => (Maybe) No physical writes to the bank, but just to the row buffer and all of writes coalesce
Simulator simple wear-leveling seems to work
Haven’t done testing too much, but the results/operations look sane
Problem: Usually no writes to the same memory location (i.e. same r_index *and* b_index) => only 1 write per row – doesn’t really show the benefit of wear-leveling
Write-Back Cache definitely improves the lifetime of PCM
No need for complicated detection or wear-leveling
Hopefully, we can say this with concrete results by next milestone!

8. Next Milestone Implementation of DRAM Write-Back Cache Policy
Comparison + Graphs!
PCM Write distribution with vs. without Wear-Leveling
PCM Write counts with vs. without DRAM Write-Back Cache
The guaranteed (the worst case) lifetime of PCM
Trade-offs in performance to lengthen the lifetime
Comprehensive Write-up
Details on DRAM WBC Policy
The performance & durability benefits due to the proposed policy