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

arXiv:2610.11398 · cs.CR · Submitted 2026-10-08 · Read on arXiv

Listen

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.

Maria Makeenkova§, Ataberk Olgun§, F. Nisa Bostancı§, İsmail Emir Yüksel§, Spiros Galanopoulos§, Onur Mutlu†

ETH Zurich · New York University

cs.CR

Submitted: 2026-10-08

Updated: 2026-10-08

Comments: 14 pages paper content, 20 pages with references and appendix, 14 figures, accepted at MICRO 2026

DOI: 10.5281/zenodo.21539625

Code: https://github.com/CMU-SAFARI/MORDOR

License: http://creativecommons.org/licenses/by/4.0/

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

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

Preventive Refresh Operation — 29× in this paper
Trace — 25× in this paper · explained in 2 episodes
Core — 23× in this paper · explained in 2 episodes
Benchmark — 8× in this paper · explained in 2 episodes
Nadia — 6× in this paper · explained in 2 episodes
Elias — 5× in this paper · explained in 2 episodes
Preventive Refresh Operation Queue — 5× in this paper
Request Age Counter — 5× in this paper
Preventive Refresh Threshold — 4× in this paper
Target Row Refresh — 4× in this paper
DRFM Address Register — 3× in this paper
Accuracy — 2× in this paper · explained in 1 episode
Benchmarking — 2× in this paper · explained in 3 episodes
Energy Efficiency — 2× in this paper · explained in 3 episodes
Robustness — 2× in this paper · explained in 5 episodes
Active Learning — 1× in this paper · explained in 6 episodes
Approximate Counting — 1× in this paper · explained in 1 episode
DRAM Per-Row Activation Counting — 1× in this paper
Reinforcement Learning — 1× in this paper · explained in 4 episodes
Transformer — 1× in this paper · explained in 2 episodes

Summary

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 them off the critical path of demand memory requests

Background on Read Disturbance and Preventive Refreshes

Modern DRAM chips are susceptible to read disturbance phenomena such as RowHammer, where repeatedly accessing (hammering) a row of DRAM cells 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 This preventive refresh operation (PRO) targets an aggressor row and prevents read disturbance-induced bitflips in its victim rows Many of these works propose using Preventive Refresh Operations (PROs) Prior works propose a naïve PRO scheduling approach that mitigates read disturbance bitflips at the cost of higher memory access latency As PRT values decrease, mitigation techniques incur higher execution time and energy consumption overheads due to a significant increase in the number of required preventive refreshes

The MORDOR Mechanism

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 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 To prevent an aggressor row from being reactivated before its PRO completes, MORDOR temporarily blacklists rows with outstanding PROs Requests that do not access a blacklisted row can continue to make progress, reducing interference caused by PROs and thereby reducing the average memory access latency, execution time, and energy consumption

Implementation Details

MORDOR is implemented in the memory controller with two minor modifications (1) The Preventive Refresh Operation Queue (PROQ), which serves as a blacklist and stores in-flight PROs MORDOR queries the PROQ to determine if issuing a memory request could cause a read disturbance bitflip (2) A 50-byte Request Age Counter (RAC) indicates the relative age of demand memory requests and PROs enqueued in the memory controller The RAC is used by the scheduler to compare the relative age of demand requests in the request queue and the PROQ The total storage required by MORDOR constitutes only 170 bytes

Key Results and Performance

Across 55 eight-core workloads, MORDOR provides an average (maximum) 21.7% (423.0%) speedup and a 22.1% (411.5%) DRAM energy reduction when integrated with four state-of-the-art read disturbance mitigation techniques that issue a significant number of preventive refresh operations for a preventive refresh threshold of 125 The greatest benefits of MORDOR are observed at an NRH value of 125 with an average speedup of 14.5% and a 14.8% reduction in energy consumption

Security Guarantees

MORDOR fully preserves the data integrity guarantees of the underlying read disturbance mitigation techniques and does not introduce a new angle of attack by delaying PROs It ensures data integrity guarantee (1) by ensuring no row is activated after its activation count reaches PRT It ensures data integrity guarantee (2) by ensuring the frequency of demand requests to an aggressor row between two PROs remains the same with MORDOR as in a setting without MORDOR It ensures data integrity guarantee (3) by observing that a 32-entry PROQ is sufficient for the vast majority of evaluated workloads

Conclusion

MORDOR reduces the execution time and DRAM energy overheads of PRO-intensive read disturbance mitigation techniques across a wide variety of configurations MORDOR is compatible with memory-controller-based read disturbance mitigation techniques that use PROs for mitigation, and requires very small modifications to the memory controller hardware MORDOR is openly and freely available at https://github.

Improvements for AI systems

Improve memory controller scheduling by implementing MORDOR to alleviate these overheads by scheduling preventive refreshes off the critical path of demand memory requests, which significantly reduces system performance degradation and energy consumption caused by preventive refresh operations.
Enhance data integrity guarantees for read disturbance mitigation techniques by ensuring No row is activated after its activation count reaches PRT and that The frequency of demand requests to an aggressor row between two PROs remains the same with MORDOR as in a setting without MORDOR.
Reduce average memory access latency for demand requests by leveraging 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.
Increase system energy efficiency by achieving a 22.1% (411.5%) DRAM energy reduction when integrated with state-of-the-art mitigation techniques at NRH=125, compared to prioritizing PROs.
Mitigate the overhead of high PRO intensity workloads by allowing requests that do not access a blacklisted row can continue to make progress, which is achieved by MORDOR temporarily blacklisting rows with outstanding PROs, thereby reducing the average memory access latency, execution time, and energy consumption.

Abstract

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.