Pith. sign in

REVIEW 3 major objections 6 minor 56 references

Heterogeneous Memory Benchmarking Toolkit

T0 review · 3 major / 6 minor · reviewed 2026-08-16 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read MEMSCOPE moves memory benchmarking into the Linux kernel, where a designated core can measure a memory module's bandwidth and latency while other cores inject controlled contention, yielding heterogeneous-memory characterizations that…

desk verdict Useful kernel-level heterogeneous memory benchmarking toolkit with a real validation story, but the paper never shows the benchmark pools are carved out of system RAM — a load-bearing gap that needs fixing before the numbers can be trusted. read the letter →

arxiv 2505.00901 v2 pith:5H5EFMQC submitted 2025-05-01 cs.AR cs.PF

Golsana Ghaemi , Gabriel Franco , Kazem Taram , Renato Mancuso This is my paper · ORCID
classification cs.ARcs.PF
keywords heterogeneousmemorykernel-levelbenchmarkingcontentionbandwidthandlatencymeasurementmemory-levelparallelismFPGA-sideDRAMBRAMreal-timeembeddedsystems
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

MEMSCOPE is a Linux kernel module that benchmarks heterogeneous memory subsystems in embedded multicore systems by moving measurement out of user space. The paper claims that only kernel-level control over physical memory allocation, cache maintenance, CPU state, and interrupts can produce contention-controlled, repeatable bandwidth and latency numbers across DRAM, FPGA-side DRAM, on-chip memory, and block RAM. On a Zynq UltraScale+ platform, the toolkit produces measurements that match an established user-space benchmark while also exposing effects user-space tools miss, such as FPGA-side DRAM traffic degrading CPU-side DRAM throughput through shared bus queue occupancy. The larger claim is that these precise measurements can directly guide memory allocation choices for real-time applications.

What carries the argument

The load-bearing object is the pairing of a device-tree-driven memory pool manager with a spinlock-synchronized core coordinator. Each hardware memory module is exposed in the device tree as a mempool node; MEMSCOPE maps that aperture with memremap and registers it as a genalloc pool, so a pool ID names one physical memory. The core coordinator sandwiches the observed core's measurement between two spin phases, guaranteeing that all stressor and idle cores have started before timing begins and have stopped before the next scenario. The workload library supplies assembly-coded sequential accesses for bandwidth and a randomized data-dependent pointer chain for latency, plus non-cacheable variants that flush or bypass caches, so the measured quantity is the target memory rather than the cache.

What would settle it

If a pool is declared with a device-tree node that points at an ordinary cached region rather than a dedicated uncached aperture, and MEMSCOPE still reports clean, low-variance results whose latency matches cache-hit latency instead of the memory module's true latency, then the memremap-based targeting is not actually measuring the intended memory.

Watch

Extended reading notes

Core claim

The central claim is that MEMSCOPE is the first kernel-level toolkit for characterizing heterogeneous memory in multicore systems, and that this level of privilege changes what can be measured. The paper argues that user-space benchmarking cannot control which physical memory a buffer lands in, cannot keep daemons and interrupts off the measured core, and cannot flush caches reliably, so noisy results obscure the true temporal behavior of each memory module. MEMSCOPE answers by turning device-tree memory nodes into allocatable kernel memory pools, running assembly microbenchmarks on a designated observed core, and synchronizing stressor cores with spinlocks so the measurement window excludes partial overlap. Its evaluations characterize DRAM, PL-DRAM, OCM, and BRAM under escalating contention; derive memory-level parallelism via Little's Law; reproduce known cache bank contention effects; and show that a streaming-write stressor can degrade a protected core's bandwidth by roughly 40 times.

Load-bearing premise

The whole measurement rests on the assumption that each device-tree mempool node names a real physical aperture that memremap maps directly and uncached, so the benchmark is actually touching that memory module and not a cached alias or a kernel-owned region.

Editorial extensions

If this is right

  • A user-space application can map its heap to a specific memory pool through the exported device files, so the characterization data can be turned directly into an allocation decision.
  • The measured memory-level parallelism values, around 4 to 5 for both DRAM types, imply that the shared bus infrastructure is the bottleneck; inter-memory interference is therefore a first-order concern for memory allocation.
  • Cache partitioning reserves cache space but does not remove hit-path bank contention, meaning isolation mechanisms must address the bank level to be effective.
  • The escalating-stress experiment design supplies a worst-case performance envelope that is directly useful for schedulability analysis in real-time systems.
  • Because pool detection is device-tree driven, adding a new memory technology such as non-volatile or remote memory requires only a new device-tree node rather than new benchmarking code.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The spinlock-sandwich synchronization pattern could be factored into a general kernel service for profiling memory quality-of-service, letting the operating system build per-application memory-sensitivity maps at runtime without recompiling benchmarks.
  • A direct testable extension of the bus-queue-occupancy story is that an interconnect-level bandwidth regulator should protect CPU-side DRAM from FPGA-side DRAM traffic more effectively than per-bank DRAM throttling; the paper does not implement such a regulator.
  • The randomized pointer-chain latency workload, being designed to defeat prefetching, could double as a calibration harness to isolate prefetch-related effects on other platforms.
  • The device-tree pool mechanism suggests a spatial-isolation use beyond benchmarking: kernel-enforced memory pools could confine safety-critical tasks to dedicated memory, though the paper does not evaluate integrity or security properties.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The paper presents MemScope, a Linux kernel module for benchmarking heterogeneous memories (PS-DRAM, PL-DRAM, OCM, BRAM) on an ARM64 embedded platform. MemScope discovers memory regions from device tree nodes with a custom compatible string, creates gen_pool-based allocators per region, and provides a workload library for bandwidth and latency measurements with configurable multi-core contention. The evaluation on a Xilinx ZCU102 characterizes DRAM variants and scratchpad memories, derives memory-level parallelism via Little's Law, reproduces a known cache-bank contention effect, validates bandwidth against IsolBench, and demonstrates application-level allocation insights using RT-Bench. The central claim is that MemScope is the first kernel-level toolkit for heterogeneous memory characterization in multicore systems, enabling precise measurements with kernel-level control over allocation, cache state, interrupts, and CPU activity.

Significance. If the results are valid, MemScope would be a valuable open-source contribution to the real-time embedded systems community, addressing genuine limitations of user-space benchmarking (C1–C5). The validation against IsolBench (Figure 10) and the reproduction of cache-bank contention on a Cortex-A53 platform (Section IV-D) are credible and demonstrate the framework's capability to capture known microarchitectural effects. The kernel-level design with explicit multi-core synchronization and performance-counter sampling is a useful engineering effort. However, the validity of all quantitative results depends critically on the correctness of the memory-pool isolation mechanism, which the manuscript does not adequately describe.

major comments (3)
  1. [Section III-B, Appendix A-A, Figure 15] The design does not describe how the memory apertures are excluded from the kernel's normal memory management. The DTS snippet in Figure 15 declares dram@10000000 with device_type="memory" and a 256 MB range; on ARM64 Linux this is exactly the node type used to register system RAM. If this range is also part of the kernel's memory map, then pages allocated from the gen_pool created by memremap can overlap with pages owned by the buddy allocator, and the benchmark may read/write live kernel data. The paper only states that these are "the slices we carve out" (Section IV-A) but provides no reserved-memory node, no "no-map" property, no mem= kernel parameter, or any other mechanism that would remove these ranges from the kernel's memory map. Establishing this reservation is mandatory before any of the reported bandwidth or latency numbers for DRAM and PL-DRAM can be accepted. Please describe the exact boot configuration (DTB, kernel command line, or U-Boot script) that ensures these apertures are private to MemScope.
  2. [Appendix A-A, Appendix A-B] The memremap flags are unspecified, which leaves the interpretation of the "non-cacheable" workloads ambiguous. If the apertures are mapped with MEMREMAP_WB (or remain in the direct map), then the supposedly non-cacheable operations (s, x, m) are actually cacheable accesses followed by dc civac, not truly uncached accesses. The first access in each loop iteration can hit in cache, and the effective mapping determines whether the measurement reflects the target memory or the cache hierarchy. Section III-E states that only normal cacheable mappings are considered, which is at odds with the non-cacheable claims in Section IV-C. Please specify the exact memremap flags used for each memory pool, and explain how the measured scratchpad results for OCM and BRAM (Figures 8 and 9) correspond to the memory module itself rather than to cached or device-mapped behavior.
  3. [Section IV-B(3), Tables II-III] The MLP calculation via Little's Law uses a latency from experiments with access pattern (l,r) or (l,w) and a bandwidth from experiments with access pattern (r,r) or (r,w). These are not the same workload on the core under observation: the latency experiment uses dependent pointer-chasing loads, while the bandwidth experiment uses sequential reads. Little's Law requires steady-state latency and bandwidth for the same traffic mix. Without a consistent pairing, the derived MLP values are not a well-defined property of the memory subsystem. Since the subsequent conclusion about a shared-bus MLP bottleneck (Section IV-B(4)) rests on the validity of these MLP numbers, the pairing must be justified or the experiments redesigned so that latency and bandwidth are measured under the same access pattern.
minor comments (6)
  1. [Section IV-A, Figures 4-13] The paper reports 500 iterations per scenario but no error bars, confidence intervals, or standard deviations. For a benchmarking toolkit that claims precision, reporting at least the median and the interquartile range for the latency and bandwidth results would strengthen statistical credibility.
  2. [Table V] In the comparison table, the entries for LENS and Heimdall appear to indicate that these tools run in kernel mode with a check mark, which contradicts the statement in Section V that "the majority are implemented in user space." Please verify the column semantics and the correctness of these entries.
  3. [Section III-C] The latency workload is described as "impossible to prefetch," but the paper does not state whether hardware prefetchers are disabled or how the randomized permutation prevents prefetching. A brief explanation or a pointer to the code would be helpful.
  4. [Appendix A-B] The non-cacheable write strategies x and y are defined differently (store followed by dc civac, and dc zva write streaming, respectively). It would be clearer to explain in the experiments where each strategy is used, especially since the y strategy is used with w* notation in Figures 13.
  5. [Throughout] The name of the toolkit is written both as "MEMSCOPE" and "MemScope" in the text and figures; please standardize the spelling.
  6. [Section IV-E] The claim that the toolkit "drives memory allocation in user-space applications" is supported only by the RT-Bench experiments in Figure 14 and Appendix B. The paper does not discuss the policies or heuristics that would actually make these allocation decisions, so the claim is stronger than the evidence presented.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: MEMSCOPE's measurements are validated against an external benchmark, and its application-level results are presented as observations rather than as predictions derived from fitted inputs.

full rationale

The paper does not contain a derivation chain in which a claimed prediction reduces by construction to its inputs. The central content is a measurement toolkit: memory pools are detected from device-tree nodes, buffers are allocated from gen_pool, and bandwidth/latency are computed from executed byte counts and elapsed time. These are direct measurements, not outputs of a fitted model. The MLP analysis uses the standard Little's Law relation (Avg. MLP = Avg. Latency × Avg. Bandwidth) on separately measured quantities; this is a derived metric, not a prediction that reintroduces its own inputs. The scratchpad and DRAM conclusions are interpretations of measured curves, not self-defined outcomes. The cache-bank-contention experiments reproduce an effect previously reported in external work [17], and the toolkit is explicitly cross-checked against the IsolBench suite: the paper states that 'The very close match in the measurements obtained using the two benchmarking approaches serves as validation that what is observed with MEMSCOPE is indeed in line with established memory performance benchmark measurement toolkits.' The application-level results in Section IV-E are described as trends that 'align with' the MEMSCOPE insights, not as predictions forced by a fitted parameter. The only self-citations are [11] (a background figure used for motivation) and [21] (an application benchmark harness used in the management study); neither supplies a load-bearing premise from which the characterization results are derived. Concerns about memremap aperture isolation or cache-bypass implementation in the appendix are experimental-validity threats rather than circularity, because the reported measurements do not become true by definition or by self-citation.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The paper introduces no fitted free parameters. Its empirical claims rest on standard hardware and mathematical assumptions: Little's Law for the MLP derivation, correct device-tree description of memory apertures, prefetch-free pointer-chasing latency measurement, and effective noise suppression by disabling interrupts and preemption. None of these are formally verified in the paper.

assumptions (4)
  • standard math Little's Law: average MLP equals average latency times average bandwidth in steady state.
    Used in Section IV-B(3), Tables II-III, to derive MLP from separately measured latency and bandwidth. Applies only if the system is in steady state and the paired experiments see identical contention, which is not established.
  • domain assumption Device tree 'mempool' nodes accurately describe physically isolated memory apertures, and memremap plus gen_pool provide direct access to those apertures.
    The entire pool manager (Section III-B, Appendix A-A) relies on the DTB to identify target memories. If apertures overlap with kernel memory or are cached, measurements are invalid.
  • domain assumption Random pointer-chaining latency workload prevents prefetching and ensures only one outstanding memory request.
    Described in Section III-C and Appendix A-B. If the Cortex-A53 or its prefetcher predicts the chain, measured latency would include cache hits and understate true memory latency.
  • domain assumption Disabling interrupts and preemption on the observed core eliminates background noise sufficiently for precise measurements.
    The key advantage claimed over user-space tools (Section II-B). The paper does not quantify residual noise, only states the mechanism.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Heterogeneous Memory Benchmarking Toolkit." pith.science (2026). https://pith.science/paper/5H5EFMQC

@misc{pith2026250500901,
  author       = {Pith},
  title        = {Pith review of: Heterogeneous Memory Benchmarking Toolkit},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/5H5EFMQC}},
  note         = {Machine review of arXiv:2505.00901}
}
read the original abstract

This paper presents an open-source kernel-level heterogeneous memory characterization framework (MemScope) for embedded systems. MemScope enables precise characterization of the temporal behavior of available memory modules under configurable contention stress scenarios. MemScope leverages kernel-level control over physical memory allocation, cache maintenance, CPU state, interrupts, and I/O device activity to accurately benchmark heterogeneous memory subsystems. This gives us the privilege to directly map pieces of contiguous physical memory and instantiate allocators, allowing us to finely control cores to create and eliminate interference. Additionally, we can minimize noise and interruptions, guaranteeing more consistent and precise results compared to equivalent user-space solutions. Running our Framework on a Xilinx Zynq UltraScale+ ZCU102 CPU-FPGA platform demonstrates its capability to precisely benchmark bandwidth and latency across various memory types, including PL-side DRAM and BRAM, in a multi-core system.

Figures

Figures reproduced from arXiv: 2505.00901 by the authors.

Figure 1
Figure 1. The problem of heterogeneous memory management consists in performing memory allocation given (1) proper characterization of the temporal [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. High-level structure of MEMSCOPE highlighting its main components and their interplay. C. Workload Library Apart from selecting the memory to benchmark, MEM￾SCOPE also allows one to select the performance metric to be measured for the chosen memory target. The specific choice depends on the particular features of the memory subsystem one wish to analyze, as well as the stress/memory contention scenarios for which in… view at source ↗
Figure 3
Figure 3. Overview of evaluation SoC including heterogeneous memory pools. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (12 more)
Figure 4
Figure 4. Figure 4: Homogeneous bandwidth results for DRAM and PL-DRAM under [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 6
Figure 6. Figure 6: Heterogeneous bandwidth results for DRAM and PL-DRAM under [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 5
Figure 5. Figure 5: Homogeneous latency results for DRAM and PL-DRAM under four [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 7
Figure 7. Figure 7: Heterogeneous latency plots for DRAM and PL-DRAM under four [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]
Figure 8
Figure 8. Figure 8: Homogeneous bandwidth results for OCM and BRAM under four stress scenarios with 32KB buffer. [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]
Figure 9
Figure 9. Figure 9: Homogeneous latency results for OCM and BRAM under four stress [PITH_FULL_IMAGE:figures/full_fig_p009_9.png]
Figure 11
Figure 11. Figure 11: Bandwidth measurement, for buffer size 256 KB, with and without [PITH_FULL_IMAGE:figures/full_fig_p009_11.png]
Figure 12
Figure 12. Figure 12: Bandwidth measurement with all cores accessing 256 KB in shared [PITH_FULL_IMAGE:figures/full_fig_p010_12.png]
Figure 13
Figure 13. Figure 13: Bandwidth measurement for core under observation always accessing [PITH_FULL_IMAGE:figures/full_fig_p010_13.png]
Figure 15
Figure 15. Figure 15: Device Tree Source (DTS) for MEMSCOPE-compatible memory nodes. (gen_pool_destroy) and performs any necessary clean￾up operations. B. Workload Library Implementation Configurable Buffer Initialization: Buffer allocations from the selected pool are performed via the gen…
Figure 16
Figure 16. Figure 16: Initialization of latency buffer for random but full walk over data-dependency buffer. [PITH_FULL_IMAGE:figures/full_fig_p016_16.png]
Figure 17
Figure 17. Figure 17: Heterogeneous memory management in more real-world applications. [PITH_FULL_IMAGE:figures/full_fig_p017_17.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

56 extracted references · 52 canonical work pages

  1. [1]

    Trends on heterogeneous and innovative hardware and software systems,

    A. Melo, J. Carretero, P. Stenstrom, S. Ranka, and E. Ayguade, “Trends on heterogeneous and innovative hardware and software systems,” Journal of Parallel and Distributed Computing , vol. 133, pp. 362–364, 2019

    work page 2019

  2. [2]

    The Linux Foundation, 2024

    The Linux Kernel Community, Linux Kernel Documentation: Remote Processor Framework. The Linux Foundation, 2024. https://docs.kernel. org/staging/remoteproc.html

    work page 2024

  3. [3]

    Openmp: an industry standard api for shared- memory programming,

    L. Dagum and R. Menon, “Openmp: an industry standard api for shared- memory programming,” IEEE Computational Science and Engineering , vol. 5, no. 1, pp. 46–55, 1998

    1998

  4. [4]

    On the off-chip memory latency of real-time systems: Is ddr dram really the best option?,

    M. Hassan, “On the off-chip memory latency of real-time systems: Is ddr dram really the best option?,” in 2018 IEEE Real-Time Systems Symposium (RTSS), pp. 495–505, 2018

    work page 2018

  5. [5]

    De- mystifying the characteristics of high bandwidth memory for real-time systems,

    K. Asifuzzaman, M. Abuelala, M. Hassan, and F. J. Cazorla, “De- mystifying the characteristics of high bandwidth memory for real-time systems,” in 2021 IEEE/ACM International Conference On Computer Aided Design (ICCAD) , p. 1–9, IEEE Press, 2021

    work page 2021

  6. [6]

    Fast and predictable non- volatile data memory for real-time embedded systems,

    M. Bazzaz, A. Hoseinghorban, and A. Ejlali, “Fast and predictable non- volatile data memory for real-time embedded systems,” IEEE Transac- tions on Computers , vol. 70, no. 3, pp. 359–371, 2021

    work page 2021

  7. [7]

    Bus-Aware Static Instruction SPM Allocation for Multicore Hard Real-Time Systems,

    D. Oehlert, A. Luppold, and H. Falk, “Bus-Aware Static Instruction SPM Allocation for Multicore Hard Real-Time Systems,” in 29th Euromicro Conference on Real-Time Systems (ECRTS 2017) (M. Bertogna, ed.), vol. 76 of Leibniz International Proceedings in Informatics (LIPIcs) , (Dagstuhl, Germany), pp. 1:1–1:22, Schloss Dagstuhl – Leibniz-Zentrum f¨ur Informa...

    work page 2017

  8. [8]

    A dynamic scratchpad memory unit for predictable real-time embedded systems,

    S. Wasly and R. Pellizzoni, “A dynamic scratchpad memory unit for predictable real-time embedded systems,” in 2013 25th Euromicro Conference on Real-Time Systems , pp. 183–192, 2013

    work page 2013

Show all 56 references
  1. [9]

    Gleipnir: a memory profiling and tracing tool,

    T. Janjusic and K. Kavi, “Gleipnir: a memory profiling and tracing tool,” SIGARCH Comput. Archit. News , vol. 41, p. 8–12, Dec. 2013

    2013

  2. [10]

    Alleria: An advanced memory access profiling framework,

    H. Brais and P. R. Panda, “Alleria: An advanced memory access profiling framework,” ACM Trans. Embed. Comput. Syst. , vol. 18, Oct. 2019

    2019

  3. [11]

    Governing with Insights: Towards Profile-Driven Cache Management of Black-Box Applications,

    G. Ghaemi, D. Tarapore, and R. Mancuso, “Governing with Insights: Towards Profile-Driven Cache Management of Black-Box Applications,” in 33rd Euromicro Conference on Real-Time Systems (ECRTS 2021) (B. B. Brandenburg, ed.), vol. 196 of Leibniz International Proceedings in Infor...

    2021

  4. [12]

    nanobench: A low-overhead tool for running microbenchmarks on x86 systems,

    A. Abel and J. Reineke, “nanobench: A low-overhead tool for running microbenchmarks on x86 systems,” in 2020 IEEE International Sym- posium on Performance Analysis of Systems and Software (ISPASS) , pp. 34–46, IEEE, 2020

    2020

  5. [13]

    Zynq ultrascale+ mpsoc data sheet: Overview (v1.8),

    Xilinx, Inc., “Zynq ultrascale+ mpsoc data sheet: Overview (v1.8),” 2019

    2019

  6. [14]

    Cortex-A53 MPCore technical reference manual (r0p4),

    ARM Holdings, “Cortex-A53 MPCore technical reference manual (r0p4),” 2018

    2018

  7. [15]

    Arm Architecture Reference Manual Armv8, for Armv8- A architecture profile (version G.a),

    A. Holdings, “Arm Architecture Reference Manual Armv8, for Armv8- A architecture profile (version G.a),” 2011

    2011

  8. [16]

    Jailhouse,

    M. Company, “Jailhouse,” 2023

    2023

  9. [17]

    Cache bank-aware denial-of-service attacks on multicore arm processors,

    M. Bechtel and H. Yun, “Cache bank-aware denial-of-service attacks on multicore arm processors,” in 2023 IEEE 29th Real-Time and Embedded Technology and Applications Symposium (RTAS) , pp. 198–208, 2023

    2023

  10. [18]

    Per-Bank Bandwidth Regulation of Shared Last-Level Cache for Real-Time Systems ,

    C. Sullivan, A. Manley, M. Alian, and H. Yun, “ Per-Bank Bandwidth Regulation of Shared Last-Level Cache for Real-Time Systems ,” in 2024 IEEE Real-Time Systems Symposium (RTSS) , (Los Alamitos, CA, USA), pp. 336–348, IEEE Computer Society, Dec. 2024

    2024

  11. [19]

    Denial-of-Service Attacks on Shared Cache in Multicore: Analysis and Prevention ,

    M. Bechtel and H. Yun, “ Denial-of-Service Attacks on Shared Cache in Multicore: Analysis and Prevention ,” in 2019 IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS) , (Los Alamitos, CA, USA), pp. 357–367, IEEE Computer Society, Apr. 2019

    2019

  12. [20]

    SD-VBS: The san diego vision benchmark suite,

    S. K. Venkata, I. Ahn, D. Jeon, A. Gupta, C. Louie, S. Garcia, S. Belongie, and M. B. Taylor, “SD-VBS: The san diego vision benchmark suite,” in 2009 IEEE International Symposium on Workload Characterization (IISWC), pp. 55–64, Oct 2009

    2009

  13. [21]

    Rt-bench: An extensible benchmark framework for the analysis and management of real-time applications,

    M. Nicolella, S. Roozkhosh, D. Hoornaert, A. Bastoni, and R. Mancuso, “Rt-bench: An extensible benchmark framework for the analysis and management of real-time applications,” in Proceedings of the 30th International Conference on Real-Time Networks and Systems , RTNS 2022, (Ne...

    2022

  14. [22]

    Intel® memory latency checker v3.11b,

    Intel, “Intel® memory latency checker v3.11b,” 2014

    2014

  15. [23]

    Taming non-blocking caches to improve isolation in multicore real-time systems,

    P. K. Valsan, H. Yun, and F. Farshchi, “Taming non-blocking caches to improve isolation in multicore real-time systems,” in 2016 IEEE Real- Time and Embedded Technology and Applications Symposium (RTAS) , pp. 1–12, 2016

    2016

  16. [24]

    The hitchhiker’s guide to programming and optimizing cxl-based heterogeneous systems,

    Z. Wang, S. Mahar, L. Li, J. Park, J. Kim, T. Michailidis, Y . Pan, T. Rosing, D. Tullsen, S. Swanson, et al. , “The hitchhiker’s guide to programming and optimizing cxl-based heterogeneous systems,” arXiv preprint arXiv:2411.02814, 2024

    2024 arXiv

  17. [25]

    Characterizing and modeling non-volatile memory systems,

    Z. Wang, X. Liu, J. Yang, T. Michailidis, S. Swanson, and J. Zhao, “Characterizing and modeling non-volatile memory systems,” in 2020 53rd Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), pp. 496–508, IEEE, 2020

    2020

  18. [26]

    Simple benchmark for memory throughput and latency resources,

    S. Siamashka, “Simple benchmark for memory throughput and latency resources,” 2016

    2016

  19. [27]

    Demystifying the memory system of modern datacenter fpgas for software programmers through microbenchmarking,

    A. Lu, Z. Fang, W. Liu, and L. Shannon, “Demystifying the memory system of modern datacenter fpgas for software programmers through microbenchmarking,” in The 2021 ACM/SIGDA International Sympo- sium on Field-Programmable Gate Arrays , FPGA ’21, (New York, NY , USA), p. 105–11...

    2021

  20. [28]

    Basic performance measurements of the intel optane dc persistent memory module,

    J. Izraelevitz, J. Yang, L. Zhang, J. Kim, X. Liu, A. Memaripour, Y . J. Soh, Z. Wang, Y . Xu, S. R. Dulloor, et al. , “Basic performance measurements of the intel optane dc persistent memory module,” arXiv preprint arXiv:1903.05714, 2019

    1903 arXiv

  21. [29]

    Softmc: A flexible and practical open-source infrastructure for enabling experimental dram studies,

    H. Hassan, N. Vijaykumar, S. Khan, S. Ghose, K. Chang, G. Pekhi- menko, D. Lee, O. Ergin, and O. Mutlu, “Softmc: A flexible and practical open-source infrastructure for enabling experimental dram studies,” in 2017 IEEE International Symposium on High Performance Computer Archi...

    2017

  22. [30]

    Measuring cache and tlb performance and their effect on benchmark runtimes,

    R. Saavedra and A. Smith, “Measuring cache and tlb performance and their effect on benchmark runtimes,” IEEE Transactions on Computers , vol. 44, no. 10, pp. 1223–1235, 1995

    1995

  23. [31]

    Measuring data cache and tlb parameters under linux,

    C. Thomborson and Y . Yu, “Measuring data cache and tlb parameters under linux,” in Proceedings of the symposium on Performance Evalua- tion of Computer and Telecommunication Systems , pp. 383–390, 2000

    2000

  24. [32]

    Automatic memory hierarchy characterization.,

    C. L. Coleman and J. W. Davidson, “Automatic memory hierarchy characterization.,” in ISPASS, pp. 103–110, 2001

    2001

  25. [33]

    Accurate cache and tlb characterization using hardware counters,

    J. Dongarra, S. Moore, P. Mucci, K. Seymour, and H. You, “Accurate cache and tlb characterization using hardware counters,” in Compu- tational Science-ICCS 2004: 4th International Conference, Krak ´ow, Poland, June 6-9, 2004, Proceedings, Part III 4 , pp. 432–439, Springer, 2004

    2004

  26. [34]

    Automatic measurement of memory hierarchy parameters,

    K. Yotov, K. Pingali, and P. Stodghill, “Automatic measurement of memory hierarchy parameters,” in Proceedings of the 2005 ACM SIG- METRICS international conference on Measurement and modeling of computer systems, pp. 181–192, 2005

    2005

  27. [35]

    Automatic measurement of instruction cache capacity,

    K. Yotov, S. Jackson, T. Steele, K. Pingali, and P. Stodghill, “Automatic measurement of instruction cache capacity,” in International Workshop on Languages and Compilers for Parallel Computing , pp. 230–243, Springer, 2005

    2005

  28. [36]

    Memory performance and cache coherency effects on an intel nehalem multi- processor system,

    D. Molka, D. Hackenberg, R. Schone, and M. S. Muller, “Memory performance and cache coherency effects on an intel nehalem multi- processor system,” in 2009 18th International Conference on Parallel Architectures and Compilation Techniques, pp. 261–270, IEEE, 2009

    2009

  29. [37]

    Measurement-based modeling of the cache replacement policy,

    A. Abel and J. Reineke, “Measurement-based modeling of the cache replacement policy,” in 2013 IEEE 19th Real-Time and Embedded Technology and Applications Symposium (RTAS) , pp. 65–74, IEEE, 2013

    2013

  30. [38]

    Reverse engineering intel last-level cache complex addressing using performance counters,

    C. Maurice, N. Le Scouarnec, C. Neumann, O. Heen, and A. Francillon, “Reverse engineering intel last-level cache complex addressing using performance counters,” in Research in Attacks, Intrusions, and Defenses: 18th International Symposium, RAID 2015, Kyoto, Japan, November 2-...

    2015

  31. [39]

    Last-level cache side-channel attacks are practical,

    F. Liu, Y . Yarom, Q. Ge, G. Heiser, and R. B. Lee, “Last-level cache side-channel attacks are practical,” in 2015 IEEE symposium on security and privacy, pp. 605–622, IEEE, 2015

    2015

  32. [40]

    Dram bender: An extensible and versatile fpga-based infrastructure to easily test state-of-the-art dram chips,

    A. Olgun, H. Hassan, A. G. Ya ˘glıkc ¸ı, Y . C. Tu˘grul, L. Orosa, H. Luo, M. Patel, O. Ergin, and O. Mutlu, “Dram bender: An extensible and versatile fpga-based infrastructure to easily test state-of-the-art dram chips,” Trans. Comp.-Aided Des. Integ. Cir. Sys., vol. 42, p. 5...

    2023

  33. [41]

    Uncovering in-dram rowhammer protection mechanisms:a new methodology, custom rowhammer patterns, and implications,

    H. Hassan, Y . C. Tugrul, J. S. Kim, V . van der Veen, K. Razavi, and O. Mutlu, “Uncovering in-dram rowhammer protection mechanisms:a new methodology, custom rowhammer patterns, and implications,” in MICRO-54: 54th Annual IEEE/ACM International Symposium on Mi- croarchitecture...

    2021

  34. [42]

    Drama: exploiting dram addressing for cross-cpu attacks,

    P. Pessl, D. Gruss, C. Maurice, M. Schwarz, and S. Mangard, “Drama: exploiting dram addressing for cross-cpu attacks,” in Proceedings of the 25th USENIX Conference on Security Symposium , SEC’16, (USA), p. 565–581, USENIX Association, 2016

    2016

  35. [43]

    Reliable reverse engineering of intel dram addressing using performance counters,

    C. Helm, S. Akiyama, and K. Taura, “Reliable reverse engineering of intel dram addressing using performance counters,” in 2020 28th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS) , pp. 1–8, 2020

    2020

  36. [44]

    Software-only reverse engineering of physical dram mappings for rowhammer attacks,

    A. Barenghi, L. Breveglieri, N. Izzo, and G. Pelosi, “Software-only reverse engineering of physical dram mappings for rowhammer attacks,” in 2018 IEEE 3rd International Verification and Security Workshop (IVSW), pp. 19–24, IEEE, 2018

    2018

  37. [45]

    NVLeak: Off-Chip Side-Channel attacks via Non-V olatile memory systems,

    Z. Wang, M. Taram, D. Moghimi, S. Swanson, D. Tullsen, and J. Zhao, “NVLeak: Off-Chip Side-Channel attacks via Non-V olatile memory systems,” in 32nd USENIX Security Symposium (USENIX Security 23) , (Anaheim, CA), pp. 6771–6788, USENIX Association, Aug. 2023

    2023

  38. [46]

    Performance evaluation and optimization of hbm-enabled gpu for data-intensive applications,

    M. Zhu, Y . Zhuo, C. Wang, W. Chen, and Y . Xie, “Performance evaluation and optimization of hbm-enabled gpu for data-intensive applications,” in Proceedings of the Conference on Design, Automation & Test in Europe , DATE ’17, (Leuven, BEL), p. 1245–1248, European Design and A...

    2017

  39. [47]

    Shuhai: Benchmarking high bandwidth memory on fpgas,

    Z. Wang, H. Huang, J. Zhang, and G. Alonso, “Shuhai: Benchmarking high bandwidth memory on fpgas,” in 2020 IEEE 28th Annual Interna- tional Symposium on Field-Programmable Custom Computing Machines (FCCM), pp. 111–119, 2020

    2020

  40. [48]

    Characterizing the performance benefit of hybrid memory system for hpc applications,

    I. B. Peng, R. Gioiosa, G. Kestor, J. S. Vetter, P. Cicotti, E. Laure, and S. Markidis, “Characterizing the performance benefit of hybrid memory system for hpc applications,” Parallel Computing, vol. 76, pp. 57–69, 2018

    2018

  41. [49]

    De- mystifying the characteristics of high bandwidth memory for real-time systems,

    K. Asifuzzaman, M. Abuelala, M. Hassan, and F. J. Cazorla, “De- mystifying the characteristics of high bandwidth memory for real-time systems,” in 2021 IEEE/ACM International Conference On Computer Aided Design (ICCAD) , pp. 1–9, 2021

    2021

  42. [50]

    Benchmarking a new paradigm: Experimental analysis and characterization of a real processing-in-memory system,

    J. G ´omez-Luna, I. E. Hajj, I. Fernandez, C. Giannoula, G. F. Oliveira, and O. Mutlu, “Benchmarking a new paradigm: Experimental analysis and characterization of a real processing-in-memory system,” IEEE Access, vol. 10, pp. 52565–52608, 2022

    2022

  43. [51]

    Evaluation of memory performance in numa architectures using stochastic reward nets,

    R. Entezari-Maleki, Y . Cho, and B. Egger, “Evaluation of memory performance in numa architectures using stochastic reward nets,”Journal of Parallel and Distributed Computing , vol. 144, pp. 172–188, 2020

    2020

  44. [52]

    Performance and availability evaluation of numa architectures,

    R. Geist and J. Westall, “Performance and availability evaluation of numa architectures,” in Proceedings of IEEE International Computer Performance and Dependability Symposium , pp. 271–280, 1996

    1996

  45. [53]

    Performance characterization of a dram-nvm hybrid memory architecture for hpc applications using intel optane dc persistent memory modules,

    O. Patil, L. Ionkov, J. Lee, F. Mueller, and M. Lang, “Performance characterization of a dram-nvm hybrid memory architecture for hpc applications using intel optane dc persistent memory modules,” in Pro- ceedings of the International Symposium on Memory Systems, MEMSYS ’19, (N...

    2019

  46. [54]

    De- mystifying cxl memory with genuine cxl-ready systems and devices,

    Y . Sun, Y . Yuan, Z. Yu, R. Kuper, C. Song, J. Huang, H. Ji, S. Agarwal, J. Lou, I. Jeong, R. Wang, J. H. Ahn, T. Xu, and N. S. Kim, “De- mystifying cxl memory with genuine cxl-ready systems and devices,” in 56th Annual IEEE/ACM International Symposium on Microarchitecture, M...

    2023

  47. [55]

    The new linux’perf’tools,

    A. C. De Melo, “The new linux’perf’tools,” in Slides from Linux Kongress, vol. 18, 2010

    2010

  48. [56]

    Test programs for measuring clock cycles and performance monitoring,

    A. Fog, “Test programs for measuring clock cycles and performance monitoring,” 2025. APPENDIX In this appendix, we provide additional implementation details to ensure reproducibility. We also provide additional experimental results that were deemed comparably less inter- estin...

    2025

Pith tools

Reviewed August 16, 2026 · model on record in the stance chip above.