PaperlayerView exact revision on arXiv

Source-linked AI summary

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

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

arXiv:2610.11398v1cs.CR

TL;DR

RowHammer mitigation can delay demand memory requests when preventive refresh operations are prioritized, creating performance and energy overheads. MORDOR schedules those refreshes around requests that do not access the target aggressor row, while retaining the underlying mitigation techniques’ data-integrity guarantees. Across six techniques and evaluated NRH values, it averages 8.6% speedup and 8.1% lower DRAM energy consumption, with 170B storage overhead.

  • Problem

    Prioritizing preventive refresh operations can delay demand requests and increase performance and energy overheads.

    Source: §3 · p. 3

  • Method

    MORDOR delays a pending PRO for requests that do not activate its target aggressor row, integrating this scheduling policy with read-disturbance mitigation techniques.

    Source: §1 · pp. 1–2

  • Results

    MORDOR averages 8.6% speedup and 8.1% lower DRAM energy consumption across six mitigation techniques and evaluated NRH values, with 170B storage overhead.

    Source: §1 · p. 2

  • Takeaways & Limitations

    MORDOR maintains the data-integrity guarantees of underlying techniques while reducing overheads from preventive refresh operations.

    Source: §1 · p. 2, §9 · p. 14

    The evaluation uses the FR-FCFS scheduler; evaluating MORDOR alongside other schedulers is left to future work.

    Source: §4.2 · p. 5

Abstract

from arXiv · show

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.

1. Introduction

Read-disturbance mitigation can impose performance and energy overheads because prioritized preventive refreshes delay demand requests. MORDOR lets unrelated requests proceed while preventing an aggressor row from being reactivated before its refresh completes.

1. Introduction

  • Prioritized PROs override the memory scheduler’s order and delay queued demand requests, with overhead increasing as preventive refresh thresholds decrease.Read disturbance arises when sufficiently frequent activations of an aggressor row cause bitflips in physically adjacent victim rows.Source: §1 · p. 1
  • A PRO need only take priority over a request that activates its target aggressor row; requests to other rows can follow the controller’s scheduling algorithm while the PRO is pending.MORDOR temporarily blacklists rows with outstanding PROs so they cannot be reactivated before refresh completion.Source: §1 · p. 1
  • MORDOR averages 8.6% speedup and 8.1% lower DRAM energy consumption across six mitigation techniques and the evaluated NRH values, with 170B storage overhead.At NRH 125, the averages reach 14.5% speedup and 14.8% lower energy consumption.Source: §1 · p. 2
  • MORDOR preserves the data-integrity guarantees of underlying mitigation techniques, including when a 32-entry PROQ fills and the controller safely reprioritizes PROs.The evaluation reports that a 32-entry PROQ is sufficient for the vast majority of evaluated workloads.Source: §1 · p. 2
  • MORDOR is integrated alongside six state-of-the-art mitigation techniques and is reported to require only 170B of storage while maintaining security against read-disturbance-induced bitflips.The evaluation uses a cycle-accurate simulator and 55 eight-core workloads, as well as memory-intensive microbenchmarks.Source: §1 · p. 2

2. Background

The background describes DRAM organization and operation, then explains RowHammer and preventive-refresh-based mitigation. It also identifies several approaches for tracking potential aggressor rows.

DRAM Organization

  • A DRAM system connects the CPU memory controller to DRAM modules, whose chips contain banks and rows of cells; each cell stores one bit as capacitor charge.A bank’s row decoder selects rows for reads or writes.Source: §2 · p. 2

DRAM Operation and Periodic Refresh

  • DRAM commands open a row with ACT, access it with RD or WR, and close it with PRE; periodic REF commands restore charge lost through leakage.The stated refresh windows are typically 64ms for DDR4 and 32ms for DDR5.Source: §2 · pp. 2–3

Read Disturbance Errors and Mitigation Techniques

  • RowHammer bitflips occur when an aggressor row is activated enough times within a limited interval; the minimum activation count is the RowHammer threshold, NRH.Mitigation techniques trigger action at a technique-specific PRT below NRH; PRO-based techniques refresh potential victim rows and prevent further aggressor activations until refresh.Source: §2 · p. 3

Read Disturbance Mitigation Techniques

  • The six evaluated PRO-based techniques span probabilistic tracking, exact activation counting, and approximate activation counting.Examples include PARA’s probabilistic adjacent-row activation and Hydra’s group and per-row counter tables.Source: §2 · p. 3

Directed Refresh Management

  • DDR5 Directed Refresh Management enables preventive refresh of victims for an arbitrary row, targeting either all banks or the same bank across bank groups.Source: §2 · p. 3

3. Motivational Analysis

Priority scheduling can put preventive refreshes on unrelated demand requests’ critical path, motivating a test of whether scheduling them less urgently reduces overhead. The evaluation finds lower performance and energy overheads with the insecure scheduling configuration, but that configuration does not guarantee data integrity.

3. Motivational Analysis

  • Priority Scheduling places PROs ahead of demand requests, overriding the memory scheduler and putting refreshes on unrelated requests’ critical path.The study tests the hypothesis that not prioritizing PROs can reduce execution-time and energy overheads.Source: §3 · p. 3

3.1. Evaluation Methodology

  • The evaluation compares six mitigation techniques in Ramulator 2.0 across 55 workloads at NRH=125, using Priority Scheduling and an insecure read-queue configuration.Priority Scheduling prioritizes PROs over all queued memory requests; the insecure configuration schedules PROs through the read queue and does not guarantee data integrity.Source: §3.1 · p. 4

3.2. Motivational Results

  • Hydra, PARA, CoMeT, and DAPPER average 23.0% speedup and 26.9% DRAM energy reduction, while ABACuS and Graphene average 0.2% for each metric.The paper attributes the more modest benefits for ABACuS and Graphene to their low overheads and few PROs at NRH=125.Source: §3.2 · p. 4
  • The insecure configuration is not suitable for reducing overheads because an aggressor may exceed the PRT before its victims are refreshed, leaving data integrity unguaranteed.The paper states that MORDOR maintains data integrity while preserving most of the insecure configuration’s performance benefits.Source: §3.2 · p. 4

4. MORDOR

MORDOR elastically schedules preventive refresh operations (PROs), letting eligible demand requests follow the memory scheduler while protecting rows with outstanding PROs. Its design includes safeguards for data integrity, bounded PROQ capacity, and integration with PRAC-based mitigation.

4. MORDOR

  • MORDOR lets demand requests that do not activate rows with outstanding PROs follow the underlying memory scheduling policy, while delaying PROs without compromising the underlying mitigation technique’s data integrity guarantees.It tracks DRAM row addresses with outstanding PROs until those PROs are served.Source: §4 · pp. 4–5

4.1. Overview

  • The PROQ stores outstanding PROs and blacklists their target rows, while the scheduler selects the oldest ready request that does not target a blacklisted row.MORDOR enqueues each PRO in order and removes it when issued; demand requests to its target row can proceed again afterward.Source: §4.1 · p. 5, §4.2 · p. 5

4.2. Detailed Design

  • A Request Age Counter preserves FR-FCFS age ordering across the request queue and PROQ; MORDOR is evaluated with FR-FCFS, while evaluation with other schedulers is left to future work.The RAC compares the relative age of ready demand requests and PROs.Source: §4.2 · p. 5

4.3. Security Analysis

  • MORDOR’s security guarantees include no activations past PRT, unchanged demand-request frequency to an aggressor between PROs, and no PROs ignored due to PROQ capacity.The underlying mitigation technique must set a safe PRT that accounts for the minimum activations that cause a bitflip.Source: §4.3 · p. 6
  • An adversarial pattern is estimated to require about 4,700 PROQ entries, although evaluated workloads do not reach such requirements.MORDOR handles capacity pressure by prioritizing PROs rather than allowing PROs to be omitted.Source: §4.3 · p. 7
  • When a 32-entry PROQ reaches 31 entries, MORDOR prioritizes the head PRO to avoid overflow, then prioritizes the last two entries if the queue fills.The queue returns to underlying-policy scheduling once it holds 30 or fewer PROs; PROs caused by other PROs can create at most one new PRO.Source: §4.3 · pp. 6–7
  • With a one-row blast radius on each side, PRT is reduced by two to account for possible activations from both neighboring rows.More generally, the reduction is 2 · blast_radius.Source: §4.3 · p. 7

4.4. Integration with PRAC

  • With PRAC, the controller can enqueue a PRO when it receives the alert back-off signal, then schedule requests to rows without outstanding PROs instead of pausing demand requests.The controller schedules the PRO under its memory scheduling policy rather than having DRAM perform the victim-row mitigation directly.Source: §4.4 · p. 7

5. Hardware Implementation

MORDOR adds a PROQ and a RAC to each memory-controller channel. For a 32-entry request queue and 32-entry PROQ, the added storage totals 170 bytes.

5. Hardware Implementation

  • MORDOR requires 170 bytes of storage: 120 bytes for a 32-entry PROQ and 50 bytes for a 64-entry RAC.The RAC tracks ordering across the PROQ and the 32-entry request queue.Source: §5 · p. 7
  • The PROQ stores outstanding PRO addresses and ordering metadata, while the RAC tracks request ordering across the PROQ and request queue.The PROQ is implemented as a content-addressable memory because the scheduler frequently queries it.Source: §5 · p. 7

6. Evaluation Methodology

The evaluation uses Ramulator 2.0 to test MORDOR with six read-disturbance mitigation techniques across four NRH values and 55 workloads. The methodology specifies DRFM choices and adjusts NRH to preserve data integrity with a fixed-size PROQ.

6. Evaluation Methodology

  • MORDOR is evaluated with Hydra, PARA, CoMeT, DAPPER, Graphene, and ABACuS at NRH values of 125, 250, 500, and 1000.The study uses Ramulator 2.0, an open-source cycle-level memory system simulator.Source: §6 · p. 8
  • The evaluation covers 55 homogeneous workloads from SPEC CPU2006, SPEC CPU2017, TPC, MediaBench, and YCSB, using Ramulator 2.0.Workloads are categorized by average PROs per kilo-instruction (PROPKI).Source: §6 · p. 8
  • The evaluation uses DRFMsb except for ABACuS, which uses DRFMab; NRH is reduced by 2 with MORDOR to preserve data integrity at a fixed 32-entry PROQ size.The reduction accounts for twice the blast radius.Source: §6 · p. 8
  • The main evaluation uses the evaluated DDR5 timing model’s DRFM latency without explicitly modeling the ACT used to populate the DRFM address register.A conservative model charging that address-setup latency only to MORDOR is evaluated separately.Source: §6 · p. 8

7. Results

Across six mitigation techniques, MORDOR reduces performance and energy overhead relative to priority scheduling, with benefits varying by PRO intensity and configuration.

7.1. Speedup and DRAM Energy Reduction

  • At NRH=125, MORDOR yields average speedups of 50.8% for Hydra and 22.8% for PARA over Priority Scheduling.Benefits are more pronounced for PRO-intensive techniques; workload traffic interactions also shape the gains.Source: §7.1 · p. 9, Figure 5 · p. 9

7.2. Hardware Overhead Analysis

  • For PROQ sizes of 32, 48, 64, and 78, lookup adds no latency because it overlaps FR-FCFS readiness checks.Despite additional PROQ-management energy, MORDOR reduces overall energy relative to priority scheduling.Source: §7.2 · pp. 9–10

7.3. Request Latency Analysis

  • MORDOR lowers average read requests delayed by PROs from 0.21 to ≪0.01 and the maximum from 3.30 to 1.36.Read latencies fall while PRO latencies rise; a slight 99th–100th-percentile read-latency increase occurs for some workloads.Source: §7.3 · pp. 10–11, Figure 9 · p. 11

7.4. Area vs. Performance Tradeoff Analysis

  • MORDOR considerably reduces execution-time overhead with only a minor area-complexity shift for most mitigation techniques.The authors conclude that pairing it with low-complexity techniques can make them more viable, even at low NRH values.Source: §7.4 · p. 11, Figure 10 · p. 11

7.5. Comparison to Insecure Configuration

  • MORDOR’s average performance overhead over Insecure is 5.2% for Hydra and below 1.2% for every other evaluated technique, while maintaining data integrity.It blocks requests to rows with outstanding PROs and lowers PRT to account for PRO reordering.Source: §7.5 · pp. 11–12, Figure 11 · p. 12

7.6. Sensitivity Studies

  • Across all techniques and workloads, MORDOR provides average speedups of 13.7%, 14.5%, and 14.8% in 8-, 16-, and 32-bank configurations.The authors conclude benefits depend mainly on PRO intensity rather than bank count.Source: §7.6 · p. 12, Figure 12 · p. 12
  • As blast radius rises from 1 to 4, MORDOR’s average cycle-count reduction falls from 14.5% to 9.9%, yet remains beneficial for PRO-intensive techniques.At blast radius 2, the average cycle-count reduction is 13.2%; DAPPER is more affected than Hydra, PARA, and CoMeT.Source: §7.6 · p. 12, Figure 13 · p. 12

7.7. DRFM Address-Setup Latency

  • With added DRFM setup latency, MORDOR reduces average execution time by 11.0% and DRAM energy by 11.4% over priority scheduling.It retains 75.5% of its execution-time benefit and 77.3% of its energy benefit; PARA is affected most.Source: §7.7 · p. 13, Figure 14 · p. 13

8. Related Work

Related work spans memory scheduling and several read-disturbance mitigation approaches; MORDOR focuses on PRO-aware scheduling alongside memory-controller-based defenses.

Memory Request Scheduling

  • Earlier memory schedulers are preventive-refresh-oblivious; BLISS blacklists application requests for fairness and performance rather than accounting for PRO scheduling.MORDOR instead considers the constraints of preventive refresh scheduling when blacklisting requests.Source: §8 · p. 13

On-DRAM-Die Read Disturbance Mitigation Techniques

  • PRAC uses per-row activation counters and signals the controller at the PRT, but counter updates require read-modify-write operations for every activation.The paper notes these updates lead to significant performance and energy overheads.Source: §8 · p. 13

Read Disturbance Mitigation Techniques

  • Memory-controller-based defenses include counter-based and probabilistic methods, and MORDOR can improve both when they issue PROs.Other approaches throttle aggressors, use software mitigation, or detect and potentially correct bitflips through integrity checking.Source: §8 · p. 14

9. Conclusion

MORDOR takes PROs off the critical path of other memory requests while maintaining data integrity, improving performance and reducing energy consumption.

9. Conclusion

  • MORDOR takes PROs off the critical path of other memory requests while maintaining data integrity against read-disturbance errors.It is designed to work with memory-controller-based mitigation techniques that use PROs and requires very small memory-controller hardware modifications.Source: §9 · p. 14

A.1. Abstract

The artifact provides data, code, traces, and scripts to reproduce and evaluate the reported results.

A.1. Abstract

  • The artifact includes Ramulator 2.0 and OpenRoad simulation code, evaluated memory traces, major results, and plotting scripts.Source: §A.1 · p. 19

A.2. Artifact check-list (meta-information)

The artifact provides a C++20/Python workflow for evaluating preventive-refresh scheduling across six RowHammer mitigations. It reports simulated cycle count and DRAM energy overhead, with simulation and hardware-analysis requirements.

Program and toolchain

  • The workflow uses C++20, Python 3, and OpenROAD hardware analysis, with Slurm and Git among the listed tools.Source: §A.2 · p. 19

Hardware

  • Each simulation requests 1 CPU and 6 GB RAM, while OpenROAD requires at least 8 GB RAM.Source: §A.2 · p. 19

Experiments and metrics

  • Experiments compare Priority, MORDOR, and insecure scheduling across six RowHammer mitigations, including PRT, bank-count, blast-radius, row-policy, and latency studies.The reported metrics are simulated cycle count and DRAM energy overhead.Source: §A.2 · p. 19

Automation and timing

  • The Python artifact driver generates and submits Slurm jobs, then runs post-processing; experiments take approximately 3–6 days depending on infrastructure.Source: §A.2 · p. 19

Archive

  • The archived artifact is identified by DOI 10.5281/zenodo.21539624.Source: §A.2 · p. 19

A.3. Description

The artifact includes source, scripts, and workload traces, with instructions for installation and reproducing reported results. Reproduction supports local or Slurm execution and can take several days for the full experiment matrix.

A.3. Description

  • The artifact’s source code, scripts, and evaluated memory traces are available through GitHub and Zenodo.The traces come from SPEC2006, SPEC2017, TPC, MediaBench, and YCSB benchmark suites.Source: §A.3.1 · p. 19, §A.3.4 · p. 19

A.3.1. How To Access.

  • A PC with 8 GiB memory and approximately 20 GiB of disk space is recommended for access and result storage.Source: §A.3.2 · p. 19

A.3.3. Software Dependencies.

  • The software dependencies include x86-64 Linux, Docker, GNU Make, CMake 3.14+, C++20, Python 3.9+, OpenSSH, Git, Bash, and rsync.Source: §A.3.3 · p. 19

A.4. Installation

  • Installation instructions clone the repository and verify the artifact with its SHA-256 checksums.Source: §A.4 · p. 19

A.5. Evaluation and Expected Results

  • The reproduction instructions cover Table 1, Figure 2, and Figures 5–14; Table 1 reproduction builds a Docker image and runs the experiment script.Source: §A.5 · p. 19, §A.5.1 · p. 19

A.5.1. Reproducing Table 1.

  • The default Table 1 run reproduces configurations used for reported area and power values, and may take several hours depending on compute resources.Source: §A.5.1 · p. 19

A.5.2. Reproducing Figures 2 and 5-14.

  • The complete paper matrix across all 55 traces can be run locally or on this Slurm cluster; in either case, omit both -classes and -traces restrictions.The cluster fetch step is completion-gated and refuses to present an incomplete experiment as a final reproduction.Source: §A.5.2 · p. 20

A.6. Methodology

  • The artifact’s methodology section points evaluators to ACM artifact-review and badging guidance and cTuning.Source: §A.6 · p. 20
Loading 2610.11398v1…