$\mathcal{RRR}$: Rethinking Randomized Remapping for High Performance Secured NVM LLC

As the workload footprint is increasing there is a need to increase the last level cache (LLC) size in processors. Increasing the LLC size with current SRAM technology is difficult because of stringent area and energy constraints. Non-volatile technologies like spin transfer torque RAM (STT-RAM) have been explored as an alternate to SRAM at LLC. However, STTRAM comes with its own set of challenges of high write latency and energy. The community has seen a quantum of works that propose to mitigate the challenges of long write latency in STTRAM LLC. On the other hand the community has also witnessed a stream of works pointing towards the cache contention based attacks at LLC and their countermeasures as well. This has lead to a chain of attacks and defence race at the LLC. Randomized caches at LLC is one such countermeasure gaining traction in the community. Ceaser, Ceaser-S, and Scatter-Cache are the state-of-the-art randomized caches. Going forward, integrating randomization with STT-RAM is crucial for enhancing both the security and performance of the STT-RAM LLC. In this paper, we observe, Ceaser, Ceaser-S, and ScatterCache exhibit a performance of <tex xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">$-28.8 \%,-7.3 \%$</tex>, and <tex xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">$-6.5 \%$</tex> respectively across a total of 97 SPEC CPU 2006, SPEC CPU 2017, and GAP workloads for a 4-core system in STT-RAM LLC compared to STT-RAM LLC with non-randomized cache. We then investigate the potential causes of the observed performance degradation and propose a technique, namely, Rethinking Randomized Remapping (<tex xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">$\mathcal{R} \mathcal{R} \mathcal{R}$</tex>), which intelligently remaps cache blocks only in the Tag array of the LLC and strategically avoids accessing the Data array. Our approach significantly recovers much of the lost performance across various workloads. With <tex xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">$\mathcal{R} \mathcal{R} \mathcal{R}$</tex>, the performance is around <tex xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">$\mathbf{- 1 1 \%}$</tex> for Ceaser, <tex xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">$\mathbf{- 3. 9 \%}$</tex> for Ceaser-S, and <tex xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">$\mathbf{- 5. 5 \%}$</tex> for Scatter-Cache for our workloads. Our experimental findings suggest that <tex xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">$\mathcal{R} \mathcal{R} \mathcal{R}$</tex> conserves <tex xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">$\sim 94 \%$</tex> of dynamic energy per remapped block and reduces remap time by <tex xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">$\sim 66 \%$</tex> compared to traditional STT-RAM remapped caches.