18-740 Milestone 2

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 • 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