Source-linked AI summary
Revisiting MemGuard Overhead: A Reproduction Report
Weifan Chen, Heechul Yun, Renato Mancuso
TL;DR
Shared-resource contention makes execution time unpredictable on multicore embedded systems, and reported MemGuard overhead figures have served as a baseline for MemPol comparisons. This report reproduces those experiments and finds that corrected MemGuard overhead is much lower, with performance highly competitive with MemPol across evaluated periods.
Problem
Shared memory contention makes memory-access latency variable and execution less predictable, while reported MemGuard overhead figures have been used to contextualize MemPol’s benefits [15, 16].
Source: §1 · pp. 1–2Method
Results
With modern decentralized MemGuard, slowdown drops from 1.79× to roughly 1.09×, or to 1.05× when older MemGuard runs the workload on a non-master core; corrected measurements show MemGuard highly competitive with MemPol across evaluated periods.
Source: §6 · pp. 8–9Takeaways & Limitations
Corrected baseline metrics provide an updated perspective for fair and accurate future evaluations of memory-bandwidth regulators.
Source: §6 · p. 9MemGuard’s spare-bandwidth sharing has no comparable MemPol feature, so that comparison illustrates MemGuard’s gain and potential gains if MemPol implements similar functionality.
Source: §5 · p. 8
Abstract
from arXiv · showhide
As an increasing number of embedded platforms incorporate multiple processing units, shared resource contention induced unpredictable execution time poses a challenge for real-time system design. Memory bandwidth regulation is a popular mitigation approach, and MemGuard is the canonical example. Recently, MemPol introduced a new bandwidth regulation mechanism, which was compared with MemGuard. Specifically, they reported significant overheads for MemGuard, citing up to a 1.79x slowdown, to contextualize MemPol's comparative benefits. This report is meant to clarify and add the necessary nuance to the experiments carried out in that prior work. Specifically, we show that the MemGuard overheads presented in these prior evaluations were unintentionally amplified as the result of using a suboptimal configuration with an older version of MemGuard, wherein the benchmark under test was pinned directly to the master core responsible for handling global timer interrupts. By faithfully reproducing these specific experiments using a modern, decentralized implementation of MemGuard, we demonstrate that the actual execution overhead drops significantly under identical conditions. Consequently, when evaluated with a properly configured recent version, MemGuard exhibits an overhead that is highly comparable to MemPol's overhead. By revisiting these baseline metrics, this report provides an updated and comprehensive perspective required for future evaluations of memory bandwidth regulators.
1 Introduction
Shared memory resources make execution times unpredictable on multicore embedded systems, motivating memory-bandwidth regulation. This report re-examines MemGuard’s reported overhead and finds that the earlier measurements were inflated by a master-core configuration, while corrected measurements make MemGuard highly competitive with MemPol.
1 Introduction
- Inter-core contention makes memory-access latency variable and execution less predictable, motivating bandwidth regulation to control memory traffic and improve temporal isolation.Timer-driven replenishment also adds execution-time overhead, with shorter periods typically triggering more frequent interrupts and higher overhead.Source: §1 · pp. 1–2
- MemPol papers [15, 16] reported MemGuard slowdowns from 1.79× at 32 µs to 1.04× at 1000 µs, using those figures to contextualize MemPol’s benefits.Accurate overhead measurement matters for system efficiency and fair comparisons among regulators.Source: §1 · p. 2
- The reported overhead was inflated by up to an order of magnitude because an older MemGuard configuration pinned the benchmark to the master core handling global timer interrupts and sending IPIs.In versions before commit 0cf14f2, centralized timer handling and IPI updates made overhead abnormally high on the master core; later versions use per-core local timers without global timer/IPI coordination.Source: §1 · p. 2
- With corrected measurements, MemGuard is highly competitive with MemPol across evaluated regulation periods and benchmarks, and reclaiming and sharing can further improve regulation performance.MemGuard can outperform MemPol, especially on memory-intensive benchmarks; its reclaiming and sharing features were not evaluated in the original MemPol papers.Source: §1 · p. 2
2 Background
This background introduces software-based bandwidth regulation and the mechanisms of MemGuard and MemPol, then situates them alongside other regulation strategies.
2.1 MemGuard
- MemGuard [14] assigns each core a memory budget Q replenished every period P; a core that exhausts its budget is throttled, enforcing a per-core limit of Q/P.It uses performance monitoring counters; later versions support independent read/write regulation using LLC refill and write-back counters [1].Source: §2.1 · p. 3
- Since commit 0cf14f2, MemGuard uses per-core local timers instead of a master-core global timer and IPIs, distributing interrupt-handling overhead uniformly across cores.Earlier versions centralized period timing and sent IPIs to signal new periods, creating asymmetric interrupt costs.Source: §2.1 · p. 3
2.2 MemPol
- MemPol [15] monitors per-core counters by polling from a separate processor and throttles through ARM’s CoreSight interface; external polling eliminates periodic timer-interrupt handling overhead.Polling can let bandwidth overshoot the assigned budget before the next reading triggers regulation.Source: §2.2 · pp. 3–4
2.3 Other Strategies
- Other strategies include MemCoRe [7], which passively monitors cache snoop requests in platforms with cache-coherent programmable logic, and ETM2 [17], which uses ETM hardware for passive event counting and minimal in-situ processing.The report also notes an ETM2 comparison of MemGuard and MemPol using a recent MemGuard version and regulation periods as short as 20 µs.Source: §2.3 · p. 4
3 Revisiting the MemGuard Overhead
The overhead evaluation reproduces MemPol’s MemGuard setup and compares it with non-master-core and newer MemGuard configurations. The older master-core setup has substantially higher slowdown than either alternative.
3 Revisiting the MemGuard Overhead
- The measured overhead is C′/C: execution time with MemGuard monitoring but taking no regulation action divided by baseline execution time without MemGuard.The experiment set the bandwidth allocation to an infeasibly large value so MemGuard delivered replenishment signals without regulating the benchmark.Source: §3 · p. 4
- Setup (1) used older MemGuard with the benchmark pinned to its master core; setup (2) used that version on another core, while setup (3) used newer MemGuard without a designated master core.In the newer version, the benchmark’s host core was randomly selected for each measurement.Source: §3 · p. 5
- At 32 µs, slowdowns were 1.79 for setup (1), 1.05 for setup (2), and 1.09 for setup (3); setups (2) and (3) were significantly lower than setup (1).The gaps narrowed at longer periods but remained significant across all evaluated periods; Figure 1 reports the experiment, with each point averaging 10 measurements and bars showing observed minima and maxima.Source: Figure 1 · p. 5, §3 · p. 5
- Pinning the benchmark to the master core is suboptimal because centralized timer handling makes its overhead higher; using a non-master core or decentralized interrupt handling yields much lower overhead.The older non-master setup can have lower overhead than the newer setup because global timing work is offloaded to the main core.Source: §3 · p. 5
4 Re-visiting MemPol and MemGuard Comparison
The section re-evaluates MemPol comparisons using modern MemGuard and reports competitive or better performance across tested benchmarks and regulation periods, correcting the contrast suggested by older MemGuard results.
4 Re-visiting MemPol and MemGuard Comparison
- Slowdown compares regulated execution while co-scheduled with other benchmarks against unregulated execution in isolation.The first experiment uses SD-VBS benchmarks regulated at 20%, 30%, or 40% of sustainable bandwidth, with IsolBench or three bandwidth benchmarks co-scheduled.Source: §4 · p. 6
- Modern MemGuard is competitive across evaluated periods and benchmarks, and sometimes outperforms MemPol for disparity even at 50 µs; Figure 2 contrasts it with older results.The bottom sub-figure shows older MemGuard results; the top shows modern MemGuard and newly evaluated MemPol data.Source: §4 · p. 6, Figure 2 · p. 6
- Modern MemGuard performs comparably to or better than MemPol across tested benchmarks and periods in the second experiment; Figure 3 contrasts it with the older configuration.This experiment uses SD-VBS benchmarks as co-scheduled contenders and includes MemPol global-regulation allocations.Source: §4 · pp. 6–7, Figure 3 · p. 7
5 Evaluating MemGuard’s Bandwidth Reclaiming and Sharing
The section evaluates MemGuard’s guaranteed bandwidth reclaiming and spare bandwidth sharing features against MemPol. Reclaiming improves performance across tested combinations, while sharing reduces slowdown for memory-intensive benchmarks; MemPol lacks a comparable sharing feature.
5 Evaluating MemGuard’s Bandwidth Reclaiming and Sharing
- With guaranteed bandwidth reclaiming, MemGuard redistributes reserved but unused bandwidth from two idle cores and improves performance more than MemPol across tested benchmark combinations.The comparison is against MemPol’s global regulation, which also redistributes unused bandwidth.Source: §5 · p. 7, Figure 4 · p. 8
- Spare bandwidth sharing significantly reduces slowdown for memory-intensive benchmarks such as disparity and mser by letting cores exploit spare bandwidth after depleting their budgets.The experiment regulates the tested benchmark and three co-scheduled bandwidth benchmarks at 20% of sustainable bandwidth each.Source: §5 · pp. 7–8, Figure 5 · p. 8
- MemPol has no feature comparable to MemGuard’s spare bandwidth sharing, so that comparison illustrates MemGuard’s performance gain rather than a comparison of equivalent features.The results also illustrate the potential gain if MemPol implemented similar functionality.Source: §5 · p. 8
6 Conclusion
The report traces MemGuard’s previously reported 1.79× slowdown to an older centralized implementation with the benchmark pinned to the timer-interrupt master core. Corrected configurations yield much lower overhead, and MemGuard is highly competitive with MemPol across evaluated periods.
6 Conclusion
- The previously reported 1.79× slowdown was an artifact of an older centralized implementation with the benchmark pinned to the master core handling global timer interrupts.Source: §6 · p. 8
- Overhead falls from 1.79× to roughly 1.09× with modern decentralized MemGuard and 1.05× with non-master pinning; MemGuard is highly competitive with MemPol across evaluated periods.Source: §6 · pp. 8–9
- Supplementary evaluations of guaranteed bandwidth reclaiming and spare bandwidth sharing show performance advantages that further reduce memory-intensive benchmark slowdown.Source: §6 · p. 9