A case for Refresh Pausing in DRAM memory systems

Abstract

DRAM cells rely on periodic refresh operations to maintain data integrity. As the capacity of DRAM memories has increased, so has the amount of time consumed in doing refresh. Refresh operations contend with read operations, which increases read latency and reduces system performance. We show that eliminating latency penalty due to refresh can improve average performance by 7.2%. However, simply doing intelligent scheduling of refresh operations is ineffective at obtaining significant performance improvement.This paper provides an alternative and scalable option to reduce the latency penalty due to refresh. It exploits the property that each refresh operation in a typical DRAM device internally refreshes multiple DRAM rows in JEDEC-based distributed refresh mode. Therefore, a refresh operation has well defined points at which it can potentially be Paused to service a pending read request. Leveraging this property, we propose Refresh Pausing, a solution that is highly effective at alleviating the contention from refresh operations. It provides an average performance improvement of 5.1% for 8Gb devices, and becomes even more effective for future high-density technologies. We also show that Refresh Pausing significantly outperforms the recently proposed Elastic Refresh scheme.

Nonblocking Memory Refresh

“…Prior works have looked at how to reduce the performance impact due to memory refresh [8,13,25,32,35,39,40,41,42,43]. Some of them have explored intelligent refresh scheduling to block fewer pending read requests [13,39,40]; however, they provide limited effectiveness.…”

“…Prior works have looked at how to reduce the performance impact due to memory refresh [8,13,25,32,35,39,40,41,42,43]. Some of them have explored intelligent refresh scheduling to block fewer pending read requests [13,39,40]; however, they provide limited effectiveness. As refresh latency increases, many later works have explored how to more aggressively address memory refresh performance overheads by skipping many required memory refresh operations [8,25,32,41,42] at the cost of reducing memory security and reliability [15,21,24,27,31]; however, this is inadequate for systems that do not wish to sacrifice security and reliability for performance.…”

Restore truncation for performance improvement in future DRAM systems

“…By default, DRAM devices are refreshed with 8K REF within 64ms, and tRFC is 208 DRAM cycles, which translates into a tREFI of 7.8 μs (i.e., 6240 DRAM cycles). As [42], the baseline adopts closed page policy, which is preferred in multicore systems [37]. Table 5 lists the workloads for evaluation.…”

“…We simulated a quad-core system with settings listed in Table 4, similar to those in [42,46]. The DRAM timing constraints follow Micron DDR3 SDRAM data sheet [5].…”

“…We compare to these schemes in the experiment section. In addition, schemes have also been proposed to reduce sensing time [15,49,55,14,46,34,9] and refresh overhead [17,50,42,10,40,36,6,8].…”