MORDOR:Mitigating Overheads of Read Disturbance Preventive Operations via Elastic Refresh Scheduling

summary

The gist

The gist: MORDOR is a new preventive refresh scheduling policy that significantly reduces system performance degradation and energy consumption caused by preventive refresh operations by scheduling

In short

MORDOR is a new policy that intelligently delays preventive refresh operations (PROs) to run outside of critical memory access paths. It leverages the fact that a PRO targeting one row can be postponed if no other demand request accesses that aggressor row. This reduces system performance degradation and energy consumption caused by high volumes of PROs.

Key concepts

Read Disturbance: This occurs when repeatedly accessing one section of DRAM (an aggressor row) causes unintended bit flips in physically nearby rows (victim rows). This phenomenon necessitates preventive refreshes to protect the victim rows from these errors.
Preventive Refresh Operation (PRO): A PRO is an operation designed to refresh victim rows before they are susceptible to read disturbance-induced bitflips. While necessary for data integrity, frequent PROs increase memory access latency and energy overhead.
MORDOR Mechanism: MORDOR integrates into the memory controller to delay PROs by scheduling them when no other demand request accesses the aggressor row being targeted. It uses a blacklist (PROQ) and a request age counter to make this intelligent scheduling decision.

Terminology used across episodes

Reinforcement Learning (RL) — explained in 26 episodes
Flow Matching — explained in 22 episodes
Quantum Fisher Information (QFI) — explained in 21 episodes
Retrieval-Augmented Generation (RAG) — explained in 21 episodes
Sample Complexity — explained in 20 episodes
Federated Learning — explained in 18 episodes

This episode discusses

The paper

MORDOR: Mitigating Overheads of Read Disturbance Preventive Operations via Elastic Refresh Scheduling · Read on arXiv

ETH Zurich · New York University

Modern DRAM chips are susceptible to read disturbance phenomena such as RowHammer, where repeatedly accessing (hammering) a row of DRAM cells (i.e., a DRAM row) induces bitflips in other physically nearby (victim) DRAM rows. A common practice to avoid such bitflips is to preventively refresh victim rows that might otherwise experience bitflips. Unfortunately, preventive refreshes cause long latencies and need to be performed urgently before the aggressor row is activated again to ensure data integrity. This is done by prioritizing them over demand memory requests, thereby potentially imposing significant delays on those requests and causing performance and energy overheads. Our goal in this work is to alleviate these overheads by scheduling preventive refreshes off the critical path of demand memory requests. We propose MORDOR, a new preventive refresh scheduling policy that significantly reduces system performance degradation and energy consumption caused by preventive refresh operations. MORDOR is integrated into the memory controller and operates alongside memory-controller-based read disturbance mitigation techniques to intelligently delay preventive refresh operations, while maintaining their data integrity guarantees. MORDOR leverages the key observation that a preventive refresh operation targeting an aggressor row can be delayed to serve any other demand memory request, as long as that memory request does not access the aggressor row. By doing so, MORDOR executes latency-critical memory requests before long-latency preventive refresh operations, while mitigating read disturbance bitflips. We evaluate MORDOR by integrating it into six state-of-the-art read disturbance mitigation techniques. Our comprehensive evaluation shows that MORDOR significantly improves system performance and energy efficiency at low area cost.

DOI: 10.5281/zenodo.21539625

Transcript

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: I'm Nadia, and with me are Elias and Priya, guest researcher.

Elias: Today's paper: "MORDOR:Mitigating Overheads of Read Disturbance Preventive Operations via Elastic Refresh Scheduling".

Nadia: The gist:

Elias: First, who's behind it and why it matters.

Paper summary: Nadia: So we’re diving into MORDOR: Mitigating Overheads of Read Disturbance Preventive Operations via Elastic Refresh Scheduling. The central thesis here is that existing methods for handling preventive refresh operations impose significant latency and energy costs because they have to be done urgently before the aggressor row gets reactivated one <ref:2610.11398#pg1,urgently before the aggressor row>.

Elias: They propose a new scheduling policy, MORDOR, which aims to alleviate those overheads by scheduling preventive refreshes off the critical path of demand memory requests instead of just letting them take precedence one <ref:2610.11398#pg1,overheads by scheduling preventive refreshes off the critical path of demand memory>. This means they want to reduce system performance degradation and energy consumption by intelligently delaying these refreshes.

Priya: It matters because traditional approaches force you to choose between data integrity and speed, often choosing integrity by slowing down every single memory access that might be affected one <ref:2610.11398#pg1>. MORDOR tries to find a middle ground where integrity is maintained while reducing that performance hit.

Nadia: The mechanism hinges on the idea that a preventive refresh operation targeting one row can be postponed to serve any other demand memory request, provided that new request doesn't try to access the aggressor row being refreshed two <ref:2610.11398#pg1>. This is the core concept for achieving this scheduling flexibility.

Elias: They put this into practice by integrating it into the memory controller with two main components: a Preventive Refresh Operation Queue, or PROQ, which acts as a blacklist of in-flight refreshes two <ref:2610.11398#pg1>. It also uses a Request Age Counter to order both demand requests and these in-flight refreshes to make scheduling decisions two <ref:2610.11398#pg1>.

Priya: So, the system has this small way of tracking what’s happening—the pending refreshes and how old the current memory requests are—to decide which one gets priority right now two <ref:2610.11398#pg1>. That tracking mechanism is what allows them to make these intelligent delays.

Nadia: The paper claims this approach significantly reduces the average memory access latency, execution time, and energy consumption across various scenarios one <ref:2610.11398#pg1>. It’s not about eliminating the refreshes themselves, but about making their timing less disruptive to your main tasks.

Elias: When we look at the numbers they present, they evaluate MORDOR alongside six other existing state-of-the-art read disturbance mitigation techniques for a range of RowHammer Thresholds, specifically from one hundred twenty-five up to <ref:2610.11398#pg1>... the text cuts off there one <ref:2610.11398#pg1>.

Priya: What this means for us on the ground is that if you're dealing with systems where these refreshes are a major bottleneck, MORDOR suggests a way to smooth out those spikes in latency and energy usage one <ref:2610.11398#pg1>. It’s an optimization technique for the hardware layer.

Nadia: Exactly. It shifts the burden from urgent, blocking refreshes to a more flexible, scheduled approach that doesn't interfere as much with the actual work your CPU is trying to get done one <ref:2610.11398#pg1>. That’s why they put this into so much focus.

Conclusion: Nadia: So we’re wrapping up our look at MORDOR: Mitigating Overheads of Read Disturbance Preventive Operations via Elastic Refresh Scheduling by Makeenkova, Olgun, Bostancı, Yüksel, Galanopoulos, Mutlu one <ref:2610.11398#pg1,MORDOR: Mitigating Overheads of Read Disturbance Preventive Operations via Elastic Refresh Scheduling>. The authors are focused on taking these necessary refresh operations and making them less painful for the system overall.

Elias: They’re essentially proposing a way to make those refreshes elastic—meaning they can be scheduled flexibly based on what other memory requests are happening in the controller one <ref:2610.11398#pg1>. It's about moving away from a rigid, urgent refresh schedule toward something that considers the context of current memory traffic.

Priya: In simple terms, this means for data systems, you get better performance and lower power usage when dealing with those background maintenance tasks because they aren't constantly interrupting the primary work flow one <ref:2610.11398#pg1>. It’s about optimizing a necessary evil.

Nadia: Right. The implication is that memory controllers can be smarter about when they execute preventive refreshes, leading to tangible gains in speed and efficiency across different workloads one <ref:2610.11398#pg1>. It shows how small changes in scheduling logic can have a measurable impact on system-wide metrics.

Elias: The main point is that you don't always have to accept the high latency penalty associated with immediate refresh execution if you can intelligently delay it, as long as the data integrity rules are strictly followed one <ref:2610.11398#pg1>. It’s about finding an optimal balance in a complex environment.

Priya: So, for those of us who only listen to this show, it means that when we talk about system performance under stress or high memory load, we should consider that scheduling these maintenance operations smartly is a real lever we can pull one <ref:2610.11398#pg1>. It’s a piece of low-level optimization that shows up in the big numbers.

More episodes

← Home