Revisiting MemGuard Overhead: A Reproduction Report Weifan Chen # Boston University, U.S.
Heechul Yun # University of Kansas, U.S.
Renato Mancuso # Boston University, U.S.
arXiv:2609.04547v1 [cs.DC] 3 Sep 2026
Abstract 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. 2012 ACM Subject Classification Computer systems organization → Real-time systems Keywords and phrases Real-time systems; Shared resource contention Digital Object Identifier 10.4230/LIPIcs.CVIT.2016.23
1
Introduction
Multi-core and heterogeneous platforms are now ubiquitous in embedded and real-time systems. In this class of systems, however, the problem of inter-core temporal interference due to the extensive sharing of hardware resources in the memory hierarchy remains an open challenge. Indeed, when multiple cores contend over limited memory resources, memory-access latency becomes highly variable, degrading predictability. Restoring desirable temporal properties in multi-core systems, while avoiding substantial hardware over-provisioning, therefore, requires careful resource management. A key resource that requires management is main memory bandwidth. A widely used software approach to mitigate the problem of uncontrolled memory bandwidth contention is memory bandwidth regulation. This encompasses a number of strategies aiming at controlling how much memory traffic a processor can originate within a fixed time window to reduce contention and improve temporal isolation. The idea of software-based memory bandwidth regulation was first proposed by Bellosa [2, 3] and later popularized by MemGuard [14], which became foundational as the first practical implementation and has since served as a baseline for many subsequent works (e.g., [5, 12, © Weifan Chen, Heechul Yun, and Renato Mancuso; licensed under Creative Commons License CC-BY 4.0 42nd Conference on Very Important Topics (CVIT 2016). Editors: John Q. Open and Joan R. Access; Article No. 23; pp. 23:1–23:10 Leibniz International Proceedings in Informatics Schloss Dagstuhl – Leibniz-Zentrum für Informatik, Dagstuhl Publishing, Germany
23:2
Revisiting MemGuard Overhead: A Reproduction Report
4, 6, 7, 15, 8]). MemGuard enforces per-core bandwidth budgets by monitoring memoryrelated events using hardware performance counters and throttling a core once its budget is exhausted; budgets are replenished periodically at a configurable replenishment period. In practice, enforcing this periodic replenishment requires timer-driven kernel activity, which inevitably introduces execution-time overhead. Moreover, the replenishment period creates a fundamental tradeoff: shorter periods improve control granularity but trigger more frequent interrupts and typically higher overhead. Because overhead directly affects both system efficiency and the fairness of comparisons among regulators, it is critical to measure and interpret MemGuard’s overhead accurately. This is especially important when overhead numbers are used as a baseline to motivate or evaluate new regulation designs. In particular, the MemPol papers [15, 16] report that MemGuard’s overhead ranges from 1.79× down to 1.04× as the replenishment period increases from 32 µs to 1000 µs, and these results have been used to contextualize MemPol’s benefits. This paper revisits the overhead results reported for MemGuard in MemPol [15, 16] through a close collaboration between the authors involved in both line of works, enabling a faithful reproduction of the original setup and a careful examination of MemGuard’s implementation evolution. Specifically, our goal is to reproduce and re-evaluate MemGuard’s replenishment-timer overhead under the conditions used in MemPol, and to refine our understanding about how that overhead impacts the MemPol-vs.-MemGuard comparisons. Our key finding is that the MemGuard overhead reported in [15, 16] was significantly inflated (by up to an order of magnitude) because it was obtained using an older MemGuard version that employed a suboptimal configuration: the implementation elected a “master” core to handle global timer interrupts and send inter-processor interrupts (IPIs), and the benchmark under analysis was pinned to that master core—exactly the situation in which interrupt handling cost is the highest. When this configuration pitfall is avoided (e.g., by pinning the benchmark to a non-master core in the older version) or when using newer MemGuard releases, the measured overhead becomes dramatically smaller (e.g., about 1.09× at 32 µs). We further explain why this discrepancy occurs by analyzing MemGuard’s internal architectural evolution over the years 1 . In versions prior to commit 0cf14f2, MemGuard centralized replenishment-timer handling on a master core and propagated replenishmentperiod updates via IPIs, creating an asymmetry in interrupt-handling costs across cores; as a result, overhead is abnormally high when the workload runs on the master core. In commit 0cf14f2 and later, MemGuard switched to a decentralized design where each core maintains its own period using a local timer without global timer/IPI coordination, making timer overhead significantly lower and more uniform across cores. Finally, using these corrected overhead measurements, we revisit the MemPol experiments that compare MemPol and MemGuard slowdowns (e.g., the evaluations corresponding to Figures 11 and 12 in [15, 16]) and discuss how the revised MemGuard overhead changes the interpretation of those results and the apparent advantage of MemPol over MemGuard at comparable regulation periods. Our findings show that with the corrected overhead metric, MemGuard demonstrates highly competitive performance compared to MemPol across all evaluated regulation periods and benchmarks, even outperforming MemPol—especially when regulating memory-intensive benchmarks. In addition, we find that MemGuard’s reclaiming and sharing features, which were not evaluated in the original MemPol papers, can significantly improve regulation performance.
1
MemGuard code repository: https://github.com/heechul/memguard
W. Chen, H. Yun, and R. Mancuso
2
23:3
Background
In this section, we provide necessary background on MemGuard [14] and MemPol [15].
2.1
MemGuard
MemGuard is a software-based memory bandwidth regulation mechanism that leverages performance monitoring counters (PMCs) widely available on modern platforms [14]. It throttles memory bandwidth by limiting the maximum number of memory transactions a core can perform within a predefined time window. Specifically, each core is assigned a memory budget Q, which is consumed as the core performs transactions. This budget is replenished periodically at a fixed interval P . If a core depletes its budget before the interval ends, it is throttled until the next replenishment. Consequently, MemGuard enforces a per-core memory bandwidth limit of Q/P . Additionally, MemGuard supports bandwidth reclamation and sharing mechanisms to improve throughput while maintaining minimum bandwidth guarantees [14]. While the original implementation of MemGuard relied on a single last-level cache (LLC) miss counter to regulate read bandwidth [14], it was later extended to support independent read and write regulation. This updated version utilizes LLC refill and LLC write-back counters to track read and write bandwidth, respectively [1]. At the beginning of each regulation period, MemGuard replenishes the budget and programs the performance monitoring unit (PMU) to deliver an overflow interrupt to a core upon budget depletion. When such an interrupt occurs, the core is throttled by scheduling a CPU-intensive, highpriority kernel thread [14]. Any throttled core is then unblocked at the start of the next regulation period. Over the years, MemGuard has undergone a significant architectural change in how it manages regulation periods via timer interrupts. In versions prior to commit 0cf14f2, a dedicated master core handled a global period timer interrupt and issued inter-processor interrupts (IPIs) to signal the start of a new period to other cores. This asymmetric design often resulted in higher interrupt handling overhead on the master core. As of commit 0cf14f2 (released Feb. 22, 2021), this reliance on a global timer and IPIs has been eliminated. Each core now manages its own period using a per-core local timer, ensuring that interrupt handling overhead is distributed uniformly across all cores.
2.2
MemPol
The following two functionalities of MemGuard play important roles in memory access regulation: (1) Monitoring the memory bandwidth consumption of a core, and (2) putting a core into a memory-idle state to throttle its memory bandwidth consumption. MemPol, also a PMC-based memory bandwidth regulation technique, achieves the said two functionalities employing quite different design and mechanisms compared to MemGuard. For MemPol to monitor memory bandwidth, per-core PMCs are accessed from outside of the monitored core by an external coprocessor via a memory-mapped interface and periodically polled. For example, Xilinx ZYNQ Ultrascale MPSoC (ZCU102) features an Application Processing Unit (APU) cluster and a Real-time Processing Unit (RPU) cluster. MemPol can be implemented on (one of) the RPU cores, while user tasks are deployed on the APU cores. The periodic polling of the PMCs forms a time series of the counter values, which MemPol uses to infer the memory bandwidth.
CVIT 2016
23:4
Revisiting MemGuard Overhead: A Reproduction Report
While periodic polling of PMCs for bandwidth monitoring is not new [13], polling in MemPol is different in that it is performed from outside of the monitored cores, by a separate processor. This allows eliminating periodic timer interrupt handling overhead. However, employing a polling approach has its own downside: the memory bandwidth can overshoot the assigned budget. This is because the updated memory bandwidth can only be evaluated at the next polling period. If during the polling period, a burst of memory transactions occurs, the memory bandwidth can already exceed the budget set by MemPol before enacting the regulation based on the newly available PMCs readings. MemGuard and MemPol also differ from how the throttling is achieved. MemPol throttles the core activities using the CoreSight debugging interface from ARM. When MemPol deems a core need to be throttled, it will instruction the core to enter debug state via the interface, and resume it in a future time.
2.3
Other Strategies
More recently, additional alternative approaches have been studied. Most notably, in platforms that include cache-coherent programmable logic (FPGA), it is possible to passively monitor cache snoop requests generated by the last-level cache controller upon a cache miss. This information can be used to accurately compute the per-core memory bandwidth consumption to perform regulation. The approach was demonstrated with the MemCoRe regulator in [7]. Furthermore, the ETM2 regulator [17] demonstrates the use of Embedded Trace Macrocell (ETM) hardware that is already included in Arm-based processors to implement memory bandwidth regulation. ETM2 relies on passive counting and minimal in-situ processing of microarchitectural events routed to the ETM. This work also includes an additional comparison between MemGuard and MemPol using one of the latest versions of MemGuard and exploring even shorter regulation periods—down to 20 µs.
3
Revisiting the MemGuard Overhead
In this section, we revisit the overhead evaluation of MemGuard in the MemPol paper ([15]; Figure 1), which was used to motivate MemPol. As discussed in Section 2.1, MemGuard uses timer interrupts to handle replenishment periods. As such, replenishment period interrupt handling cost is added overhead that can impact application performance, even when the application never exceeds its memory bandwidth budgets. We first define the key overhead metric in this context and then present the experimental results. Consider a platform where the benchmark under analysis is the only user task active in the system. In this context, the overhead is calculated as the slowdown that the benchmark suffers when MemGuard monitors the core to which the benchmark is pinned but performs no active regulation action. This is achieved by setting the allocated bandwidth of the core to an infeasibly large value, so that MemGuard will only deliver replenishment signals but take no regulation actions. Let C ′ be the execution time of a benchmark under the said condition. Let C be the baseline execution time of a benchmark. This is the execution time without MemGuard. The replenishment period induced overhead is defined as C ′ /C. As in the original MemPol paper, all experiments in this work are conducted on Xilinx Zynq UltraScale+ ZCU102 platform that features four Arm Cortex-A53 application cores with a main memory subsystem comprised of a single DDR4 controller. We measured the overhead under various replenishment periods, ranging from 32us to 1ms, using the
W. Chen, H. Yun, and R. Mancuso
23:5
bandwidth benchmark from the IsolBench [10]. For a specific setup and replenishment period, ten measurements are conducted. We conducted the measurement with three different setups: (1) Using the older version of MemGuard, i.e. the same version as used in MemPol, and where the benchmark is pinned to the same core as the main core of MemGuard; (2) Same as (1), but where the benchmark is pinned to another core; (3) Using a newer version 67eb0d8 of MemGuard. The newer MemGuard does not elect a main core, thus the host core of the benchmark is randomly selected in each measurement. In Figure 1, the blue curve representing the results of setup (3), shows that the overhead is significantly lower than that in setup (1) whose results are represented by the yellow curve. The setup (2), represented by the green curve, has the smallest overhead. 1.8
(conf 1) Old MemGuard w/ same core (conf 2) Old MemGuard w/ diff core (conf 3) New MemGuard
Slowdown (ratio)
1.7 1.6 1.5 1.4 1.3 1.2 1.1 1.0 0
200
400
600
800
MemGuard Regulation Period [us]
1000
Figure 1 The yellow, blue, and green extrapolated curves show the results of setup (1), (3), and (2) respectively. Each data point is the average of 10 measurements. The error bar indicates the min/max observed value across the 10 measurements. The experiments show that systematically the setup (2) and (3) have significant lower overhead than setup (1). At 32µs replenishment period, the slowdowns for setup (1),(2), and (3) are 1.79, 1.05, and 1.09 respectively.
The experiments show that the second and third setups have significantly lower overhead than the first setup. At a 32 µs replenishment period, for example, the slowdowns for the first, second, and third setups are 1.79, 1.05, and 1.09 respectively. The gaps are narrow in the longer periods but still significant and persistent across all evaluated regulation periods. As discussed in Section 2.1, the first setup is suboptimal because it forces the measured benchmark to run on the master core, which incurs higher overhead due to its centralized design. Using the second (running the benchmark on non-master core in the old MemGuard version) or the third (using newer MemGuard version with de-centralized interrupt handling) configurations, on the other hand, incur dramatically lower overheads. Notice, the second configuration (old MemGuard with different cores) has even lower overhead than the third configuration (new MemGuard). This is because the old centralizes period timing on a separate main core. The user core receives an inter-process interrupt only to reset and rearm its local PMU counter. The new replaces this with a per-core high-resolution timer, so the user core directly handles the periodic timer interrupt and its control work. Consequently, the old can impose less overhead by offloading global timing work to the main core. In the following, we will compare the results obtained using the first and third configurations to illustrate how significantly it affects the performance comparison between MemGuard and MemPol.
CVIT 2016
Revisiting MemGuard Overhead: A Reproduction Report
4
Re-visiting MemPol and MemGuard Comparison
The original MemPol paper includes two sets of experiments comparing the slowdown caused by MemPol and MemGuard (Fig.11 and Fig.12 in [15]). Because the setup of MemGuard in these experiments suffered from high overhead, this section presents the re-evaluation of the same experiments with a more up-to-date version of MemGuard (67eb0d8), and presents a side-by-side comparison. The experiments compare the slowdown of the execution time of benchmarks. The slowdown is defined as the ratio of the execution time of the benchmarks under regulation while co-scheduled with other benchmarks, to the unregulated execution time of the benchmarks in isolation. The first experiment uses SD-VBS [11] as benchmarks which are regulated at 20%, 30%, and 40% of the sustainable bandwidth, which is empirically estimated to be 1000MB/s on the ZCU102 platform [9] we used for evaluation. Either one bandwidth benchmark from IsolBench [10] regulated at 60% of the sustainable bandwidth, or three bandwidth each regulated at 20% of the sustainable bandwidth, are used as co-scheduled benchmarks. All bandwidth is conducting memory read access. Figure 2 presents the results.
solo
3x 1x bench bench
solo
3x 1x bench bench
Slowdown (Ratio)
MemPol 50 µs
Slowdown (Ratio)
23:6
3 2 1 0 3 2 1 0 3 2 1 0
3 2 1 0 3 2 1 0 3 2 1 0
MemPol 100 µs
MemPol 200 µs
MemGuard 50 µs
MemGuard 100 µs
MemGuard 200 µs
MemGuard 1000 µs
disparity disparity disparity 20 % 30 % 40 %
mser 20 %
mser 30 %
mser 40 %
sift 20 %
sift 30 %
sift 40 %
stitch 20 %
stitch 30 %
stitch 40 %
tracking tracking tracking 20 % 30 % 40 %
disparity disparity disparity 20 % 30 % 40 %
mser 20 %
mser 30 %
mser 40 %
sift 20 %
sift 30 %
sift 40 %
stitch 20 %
stitch 30 %
stitch 40 %
tracking tracking tracking 20 % 30 % 40 %
Figure 2 The top sub-figure shows the results of modern MemGuard in which the MemPol data is also newly evaluated, the bottom shows the results from older MemGuard with overhead abnormality directly taken from the old data. Per sub-figure, each row represents the configuration of co-scheduled benchmark(s), while each column represents the benchmark under test at a specific allowed memory bandwidth. Each bar is the average of 10 measurements, with vertical bars indicating the observed min/max overhead.
Note first that the bottom sub-figure corresponds to Figure 11 in the original MemPol paper, which suggests that MemGuard suffers from significantly higher overhead compared to MemPol, especially at short regulation periods. In stark contrast, the top sub-figure— obtained using a recent version of MemGuard—shows that MemGuard delivers competitive performance compared to MemPol across all evaluated regulation periods and benchmarks. In fact, for memory-intensive benchmarks such as disparity, MemGuard occasionally outperforms MemPol even at the 50 µs regulation period. This is particularly noteworthy given MemGuard’s expected disadvantage due to the higher frequency of timer interrupts at smaller regulation periods. The second experiment has two differences compared with the first: (1) disparity, sift, and tracking from SD-VBS are used as co-scheduled benchmarks instead of IsolBench. The regulation for both cores are the same; (2) MemPol conducts global regulation which allows the allocation of unused global bandwidth (Subsection 2.2). More specifically, the benchmark
W. Chen, H. Yun, and R. Mancuso
tracking sift disparity
Slowdown (Ratio) Slowdown (Ratio)
tracking sift disparity
MemPol global 50 µs 3 2 1 0 3 2 1 0 3 2 1 0
3 2 1 0 3 2 1 0 3 2 1 0
MemPol global 200 µs
MemPol 50 µs
23:7
MemPol 200 µs
MemGuard 50 µs
MemGuard 200 µs
MemGuard 1000 µs
disparity 20 %
disparity 30 %
mser 20 %
mser 30 %
sift 20 %
sift 30 %
stitch 20 %
stitch 30 %
tracking 20 %
tracking 30 %
disparity 20 %
disparity 30 %
mser 20 %
mser 30 %
sift 20 %
sift 30 %
stitch 20 %
stitch 30 %
tracking 20 %
tracking 30 %
Figure 3 The top sub-figure shows the results of modern MemGuard in which the MemPol data is also newly evaluated, the bottom shows the results from older MemGuard with overhead abnormality directly taken from the old data. Per sub-figure, each row represents the selected co-scheduled contender benchmark. Each column represents the benchmark under test at a specific memory bandwidth. For example, the first column second row represents the overhead of disparity contended by sift. Each bar is the average of 10 measurements with vertical bar indicating the observed min/max.
under test is regulated at 20% and 30% of the sustainable bandwidth, with 60% and 40% of the global unused bandwidth allocation respectively. Figure 3 presents the results. Consistent with the first experiment, these new results (top sub-figure) demonstrate that modern MemGuard performs comparably to or better than MemPol across all tested benchmarks and periods. This corrects the findings in the original MemPol paper (bottom sub-figure), which utilized a suboptimal configuration. Note that this comparison focuses on basic regulation; MemPol’s global regulation results (first two columns) are discussed in the following section.
5
Evaluating MemGuard’s Bandwidth Reclaiming and Sharing
This section presents two sets of experiments to evaluate two additional features of MemGuard: guaranteed bandwidth reclaiming and spare bandwidth sharing [14], against MemPol. These features can further improve the performance and effectiveness of MemGuard, but were not evaluated in the original MemPol paper [15]. This section aims to fill the gap by comparing them with MemPol’s regulation capability. In the first experiment, we compare MemPol’s global regulation with MemGuard’s (guaranteed) bandwidth reclaiming feature, as they both aim to re-distribute the sustainable bandwidth from under utilized cores to the needing ones at run-time. The basic experiment setup is the same as Figure 3 except that we include MemGuard with reclaiming enabled. Figure 4 shows the results. With reclaiming enabled, MemGuard can re-distribute reserved but unused bandwidth from the two idle cores in the system to the demanding cores that execute the benchmarks, resulting in significantly improved performance across all tested benchmark combinations. In contrast, MemPol also redistributes unused bandwidth, but its performance gains are less significant than those of MemGuard. In the second experiment, we evaluate MemGuard’s spare bandwidth sharing feature. The experiment setup is as follows: the benchmark is regulated at 20% of sustainable bandwidth, while 3 co-scheduled bandwidth benchmarks are deployed on three other cores, regulated at 20% each. This is essentially a subset of experiments presented in Figure 2, except that the
CVIT 2016
Revisiting MemGuard Overhead: A Reproduction Report
Slowdown (Ratio)
tracking/vga sift/vga disparity/vga
MemPol global 200 µs
MemPol 200 µs
MemGuard 200 µs
MemGuard-BR 200 µs
3 2 1 0 3 2 1 0 3 2 1 0
disparity/vga 30 %
mser/vga 30 %
sift/vga 30 %
stitch/vga 30 %
tracking/vga 30 %
Figure 4 A subset of experiments from Figure 3, plus the evaluation of MemGuard with the guaranteed bandwidth reclaim mode (denoted as ‘MemGuard-BR’) enabled.
performance of MemGuard with spare bandwidth sharing feature enabled is also evaluated.
3× IsolBench
MemPol 200 µs Slowdown (Ratio)
23:8
MemGuard 200 µs
MemGuard-SS 200 µs
3 2 1 0
disparity/vga 20 %
mser/vga 20 %
sift/vga 20 %
stitch/vga 20 %
tracking/vga 20 %
Figure 5 A subset of experiments from Figure 2, plus the evaluation of MemGuard with the spare bandwidth sharing mode (denoted as ‘MemGuard-SS’) enabled.
Figure 5 shows the results, which clearly show the spare bandwidth sharing of MemGuard significantly reduce the slowdown of memory-intensive benchmarks under regulation, such as disparity and mser. This is because within a replenishment period, all the cores quickly deplete their respective budgets. Consequently, MemGuard allows cores to continue to exploit the spare bandwidth for better throughput. Note that, for the spare bandwidth sharing feature, though some experiment results of MemPol are presented aside, MemPol does not have a comparable feature. Thus the comparison is to illustrate the performance gain of MemGuard’s spare bandwidth sharing, not to certain MemPol features. Secondly, evaluating MemGuard’s spare bandwidth sharing feature illustrates the potential performance gain if MemPol implements similar functionalities.
6
Conclusion
This report re-evaluated the execution-time overhead of the MemGuard memory bandwidth regulator to clarify the significantly inflated overheads presented in prior evaluations [15, 16]. By faithfully reproducing the original experimental setups, we demonstrated that the previously reported 1.79x slowdown was an artifact of an older, centralized MemGuard implementation where the benchmark under test was pinned directly to the master core responsible for handling global timer interrupts. When evaluated using a modern, decentralized version of MemGuard—or by simply pinning workloads to non-master cores in the older version—the overhead drops dramatically from 1.79X to roughly 1.09x and 1.05x, respectively. With these corrected baseline metrics,
W. Chen, H. Yun, and R. Mancuso
23:9
MemGuard demonstrates highly competitive performance compared to MemPol across all evaluated regulation periods. In addition, our supplementary evaluations of MemGuard’s guaranteed bandwidth reclaiming and spare bandwidth sharing mechanisms highlight significant performance advantages that further reduce the slowdown of memory-intensive benchmarks. Ultimately, this report provides the updated and comprehensive perspective necessary for fair and accurate future evaluations of memory bandwidth regulators. References 1
2 3 4
5
6
7
8
9
10
11
12
13
14
Michael G Bechtel and Heechul Yun. Denial-of-Service Attacks on Shared Cache in Multicore: Analysis and Prevention. In IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS), 2019. Frank Bellosa. Memory access - the third dimension of scheduling. Technical Report TR-I497-01, January 1997. URL: http://i30www.ira.uka.de/. Frank Bellosa. Three Dimensions of Scheduling. PhD thesis, University of Erlangen-Nürnberg, Germany, November 27 1998. Farzad Farshchi, Qijing Huang, and Heechul Yun. BRU: Bandwidth regulation unit for real-time multicore processors. In IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS), pages 364–375. IEEE, 2020. Jonas Flodin, Kai Lampka, and Wang Yi. Dynamic budgeting for settling dram contention of co-running hard and soft real-time tasks. In IEEE international symposium on industrial embedded systems (SIES), pages 151–159. IEEE, 2014. Robert Gifford, Neeraj Gandhi, Linh Thi Xuan Phan, and Andreas Haeberlen. Dna: Dynamic resource allocation for soft real-time multicore systems. In IEEE real-time and embedded technology and applications symposium (RTAS), pages 196–209. IEEE, 2021. Ivan Izhbirdeev, Denis Hoornaert, Weifan Chen, Alexander Zuepke, Youssef Hammad, Marco Caccamo, and Renato Mancuso. Coherence-aided memory bandwidth regulation. In IEEE RealTime Systems Symposium (RTSS), pages 322–335, 2024. doi:10.1109/RTSS62706.2024.00035. Hayeon Park, Jiwoong Lee, Hoyong Lee, Taekyoung Kwon, Wan Choi, Sangmi Moon, and Chang-Gun Lee. A field practical approach to memory bandwidth allocation for consolidating multi-domain automotive applications on a single soc. In IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS), pages 95–107. IEEE, 2025. Parul Sohal, Rohan Tabish, Ulrich Drepper, and Renato Mancuso. E-warp: A system-wide framework for memory bandwidth profiling and management. IEEE Real-Time Systems Symposium (RTSS), pages 345–357, 2020. Prathap Kumar Valsan, Heechul Yun, and Farzad Farshchi. Taming Non-blocking Caches to Improve Isolation in Multicore Real-Time Systems. In Real-Time and Embedded Technology and Applications Symposium (RTAS), 2016. Sravanthi Kota Venkata, Ikkjin Ahn, Donghwan Jeon, Anshuman Gupta, Christopher Louie, Saturnino Garcia, Serge Belongie, and Michael Bedford Taylor. SD-VBS: The san diego vision benchmark suite. In IEEE International Symposium on Workload Characterization (IISWC), pages 55–64, 2009. Heechul Yun, Waqar Ali, Santosh Gond, and Siddhartha Biswas. Bwlock: A dynamic memory access control framework for soft real-time applications on multicore platforms. IEEE Transactions on Computers, (1):1–10, 2017. Heechul Yun, Gang Yao, Rodolfo Pellizzoni, Marco Caccamo, and Lui Sha. Memory access control in multiprocessor for real-time systems with mixed criticality. In Euromicro conference on real-time systems (ECRTS), pages 299–308. IEEE, 2012. Heechul Yun, Gang Yao, Rodolfo Pellizzoni, Marco Caccamo, and Lui Sha. MemGuard: Memory Bandwidth Reservation System for Efficient Performance Isolation in Multi-core Platforms. In Real-Time and Embedded Technology and Applications Symposium (RTAS), 2013.
CVIT 2016
23:10
Revisiting MemGuard Overhead: A Reproduction Report
15
16
17
Alexander Zuepke, Andrea Bastoni, Weifan Chen, Marco Caccamo, and Renato Mancuso. MemPol: Policing core memory bandwidth from outside of the cores. In IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS), pages 235–248. IEEE, 2023. Alexander Zuepke, Andrea Bastoni, Weifan Chen, Marco Caccamo, and Renato Mancuso. Mempol: polling-based microsecond-scale per-core memory bandwidth regulation. Real-Time Systems, pages 1–44, 2024. Alexander Zuepke, Ashutosh Pradhan, Daniele Ottaviano, Andrea Bastoni, and Marco Caccamo. Mempol: Policing core memory bandwidth from outside of the cores. In IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS). IEEE, 2026.