Pith. sign in

REVIEW 4 major objections 5 minor 37 references

CXL-Interference: Analysis and Characterization in Modern Computer Systems

T0 review · 4 major / 5 minor · reviewed 2026-08-12 · deepseek-v4-flash

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

Pith's one-line read On two real CXL hardware platforms, background CXL non-temporal store traffic suppresses concurrent main memory bandwidth by up to 93.2%.

desk verdict First real-hardware CXL interference study with a striking 93% suppression finding; external validity is the main risk, but the paper deserves peer review. read the letter →

arxiv 2411.18308 v1 pith:YBK6RRA4 submitted 2024-11-27 cs.AR cs.PF

Shunyu Mao , Jiajun Luo , Yixin Li , Jiapeng Zhou , Weidong Zhang , Zheng Liu , Teng Ma , Shuwen Deng This is my paper · ORCID
classification cs.ARcs.PF
keywords CXLmemoryinterferencenon-temporalstoreTableofRequest(TOR)mainbandwidthSSDregulationperformancecharacterization
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

This paper aims to establish that CXL memory devices are not passive, isolated components: when they run alongside ordinary DRAM and SSD workloads, co-tenancy can substantially degrade the other workloads. The authors measure this on two real CXL systems, one with an ASIC-based and one with an FPGA-based CXL memory expander, and report that non-temporal store (ntst) traffic from the CXL device suppresses concurrent main-memory bandwidth by up to 93.2% and also hurts SSD throughput. They trace the cause to long occupancy of the Table of Request (TOR), the queue tracking pending cache and uncore transactions, and show that throttling CXL traffic via CPU quotas or memory-bandwidth caps recovers most of the lost bandwidth. If correct, CXL memory management and co-scheduling policies must account for interference, not just capacity and latency.

What carries the argument

The load-bearing mechanism is the Table of Request (TOR), a queue between cores and the last-level cache that tracks pending Cache Home Agent (CHA) transactions, with one TOR per core and per PCIe interface. The paper argues that CXL traffic, particularly non-temporal store (ntst), occupies the TOR for long periods, delaying requests from co-running processes. This explains why CXL ntst is far more disruptive than CXL load/store, why MOVDIR64B (which leaves the write-combining buffer more quickly) causes less suppression, and why cache-partitioning remedies fail against ntst, which bypasses cache allocation. Supporting evidence comes from uncore performance counters for TOR occupancy and inserts, plus kernel hotspot shifts in memcpy and copyout functions.

What would settle it

Run the same microbenchmark on a third-generation CXL system with a different uncore architecture, such as an AMD or ARM server or a different CXL controller, and check whether 16 CXL non-temporal-store threads still suppress concurrent main-memory bandwidth by more than 50% and whether the TOR occupancy counter still rises by thousands of times. If the suppression is small or the counter does not move, the TOR-congestion explanation and the generality claim fail.

Watch

Extended reading notes

Core claim

The central claim is that CXL memory traffic, especially non-temporal stores, interferes with co-running memory and storage workloads in real servers, and the interference is asymmetric: CXL hurts main memory (MMEM) and SSD much more than they hurt CXL. On System B, 16 CXL ntst threads reduce concurrent MMEM bandwidth by 93.2%, while CXL load/store traffic causes over 40% suppression; on both systems SSD random-write throughput drops by roughly 60%. The authors' reverse-reasoning analysis attributes the mechanism to TOR congestion: CXL miss requests occupy the Table of Request queue for long periods, inflating L2 miss latency by 15x and TOR occupancy counters by about 4090x. They then demonstrate that software regulation, via cgroup CPU quotas, frequency scaling, and memory-bandwidth allocation, can restore MMEM bandwidth to 92%-99% of baseline at a small cost in CXL bandwidth.

Load-bearing premise

The paper's quantitative claims assume that what happened on these two specific CXL test machines, one ASIC-based and one FPGA-based, also happens on other CXL controllers, PCIe topologies, and server uncore designs.

Editorial extensions

If this is right

  • If CXL ntst traffic is left unregulated, co-located main-memory and NVMe/SAS workloads can lose most of their bandwidth, a practical constraint for CXL memory pooling in shared clouds.
  • Software regulation is a workable first line of defense: cgroup CPU quotas recover about 92% of MMEM bandwidth, and memory-bandwidth allocation recovers 99%, 95%, and 98% across the three tested applications, at a cost of only a few GB/s of CXL bandwidth.
  • Because ntst bypasses the cache, cache-partitioning hardware mechanisms will not mitigate this interference; device-side or TOR-side regulators are the indicated hardware path.
  • CXL load traffic can sometimes improve SSD and filesystem workload performance, up to 21.2% for RocksDB on System A, an effect tied to reduced instruction counts once CXL memory bandwidth exceeds about 8 GB/s.
  • The asymmetry of interference means CXL memory behaves as a noisy neighbor to DRAM, while DRAM and SSD are mild neighbors to CXL, which matters for memory-tiering and co-scheduling decisions.
  • The paper's own mitigation results imply that identifying and throttling high-bandwidth CXL ntst processes is sufficient to restore most lost performance, without redesigning the memory system.

Reading between the lines

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

  • If the TOR-occupancy mechanism is the true bottleneck, the interference magnitude should scale with the number of in-flight CXL misses and with the number of CXL devices sharing the uncore; a system with multiple CXL expanders on the same socket should show suppression even worse than 93%.
  • The two-platform measurement leaves open which CXL controller, PCIe topology, or uncore design points are protected; a third platform with a different uncore architecture, such as AMD or ARM, could confirm or bound the generalization.
  • The bandwidth-restoration data support an adaptive online policy: continuously monitor CXL ntst bandwidth and TOR occupancy, then throttle CXL traffic with CPU quotas or MBA whenever co-running bandwidth-sensitive workloads are detected; the paper does not specify such a controller, but its measurements provide the needed input-output relationship.
  • Since MOVDIR64B interferes less than ntst, kernel and compiler writers could reduce interference by preferring write-combining direct stores for CXL memory updates, provided write-atomicity guarantees are acceptable.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. This manuscript presents an empirical study of performance interference between CXL memory traffic and host main memory (MMEM) and SSD storage traffic. The authors built a configurable microbenchmark and ran it on two real CXL systems: System A (Montage ASIC CXL memory, SAS SSD, CentOS 7) and System B (Intel Agilex FPGA CXL memory, NVMe SSD, Ubuntu). They report that CXL non-temporal stores (ntst) can suppress concurrent MMEM bandwidth by up to 93.2% and SSD bandwidth by up to 61.3% in microbenchmarks, with real applications seeing up to 90% degradation. They propose a reverse-reasoning analysis using uncore PMU counters and kernel profiling, attributing the main mechanism to table-of-request (TOR) congestion. They also evaluate CPU-quota cgroup limiting, frequency scaling, and Intel MBA as mitigations, claiming recovery to 92-99% of original MMEM bandwidth. The paper draws six insights and practical hardware/software takeaways, and claims to be the first characterization of CXL interference on real hardware.

Significance. If the central measurements are robust, this is a useful addition to the CXL characterization literature: it goes beyond isolated CXL performance and addresses co-tenant interference, which is relevant for real CXL adoption. The use of two real CXL devices (ASIC and FPGA) and the cross-validation of instruction-level bandwidth measurements with CXL PMU counters are concrete strengths; the counter agreement (e.g., 13169 MB/s versus 13342 MB/s for the same configuration) is a good reliability check. The paper also offers a falsifiable design suggestion (specialized TOR for slow-tier memory) and evaluates practical mitigations. However, the generality of the quantitative claims and the causal mechanism are not fully established by the evidence presented, so the contribution is currently strongest as a platform-specific characterization rather than a general law about CXL interference.

major comments (4)
  1. [§III.B, Table III] The headline figures, including the 93.2% MMEM suppression under CXL ntst on System B, are reported only as the maximum interference across thread-count configurations. No variance, confidence interval, or per-thread distribution is given for these maxima, so a reviewer cannot determine whether 93.2% is a robust worst case or a single outlier point. The problem is compounded by the footnote to Figure 4, which states that 'in certain scenarios, the results are unstable and exhibit significant fluctuations' and that such cases are represented as 0; this can make severe but noisy interference appear as no influence. To support Insight #1 and the abstract's central claim, the paper must report the full distribution (or at least median, interquartile range, and number of runs) for the configurations that produce the maximum, and it must report unstable scenarios separately instead of encoding them as zero.
  2. [§II, Table II] The external-validity claims are broader than the data. Only two platforms are evaluated, and they differ simultaneously in CXL device (Montage ASIC versus Intel Agilex FPGA), SSD interface (SAS versus NVMe), CPU model, memory capacity, and OS/kernel. Since no variable is varied in isolation, the observed up-to-93% suppression and the general statement that CXL traffic significantly impairs concurrent MMEM and SSD traffic cannot be separated from implementation or platform effects. The paper should either add a controlled comparison (for example, the same CXL device on a second host, or a second device on the same host) or explicitly scope all conclusions and takeaways to the two tested configurations. A limitations paragraph naming this threat to external validity is required before the results can be presented as a general characterization of CXL interference.
  3. [§III.C, Table IV, Insight #2 / H1] The TOR-congestion mechanism is asserted more strongly than the evidence supports. The supporting data are ratios of PMU events under interference versus no interference (for example, unc_cha_tor_occupancy.ia_miss ratio 4090x and unc_cha_tor_inserts.ia_miss ratio 155x), from which the paper 'deduces' that CXL traffic occupies TOR for a lengthy period. These counters are consistent with the hypothesis, but they do not establish causation or exclusivity: no direct manipulation of TOR capacity, occupancy threshold, or device-side traffic is performed, and the very large occupancy ratio could reflect measurement semantics such as accumulated cycles rather than queue-depth saturation. To support H1, the paper should report TOR occupancy or utilization as a function of injected CXL ntst bandwidth and show that MMEM/SSD interference tracks TOR utilization, or explicitly relabel Insight #2 as a hypothesis consistent with the counters rather than a demonstrated root cause.
  4. [§IV, Figure 4] The real-application evaluation uses the same maximum-only reporting and additionally truncates unstable results to zero. Figure 4's y-axis is logarithmic but includes values labeled 0, which cannot be represented on a log scale; the footnote indicates that unstable scenarios are set to 0. It is therefore unclear whether the many zero or near-zero bars (for example, several Type B and Type D cases) reflect no interference or dropped measurements. Since the paper uses this figure to claim that 'in most cases there is solid contention and interference,' the zeros need to be disaggregated: how many runs were unstable, what was the variance, and which scenarios were dropped. Without this, the real-application conclusions and the 'up to 20.8x performance decline' claim in Section IV.B are not fully auditable.
minor comments (5)
  1. [Abstract] The abstract refers to 'CXL-Interplay' while the title and the rest of the paper use 'CXL-Interference'; please make the naming consistent.
  2. [Table III, colorbar] The colorbar ranges are ambiguous: 'Mild Suppression', -5% to -10%, and 'Moderate Suppression', -40% to -10%, overlap at -10%, and 'No Influence' within -5% leaves the boundary at -5% undefined. Please clarify the exact intervals.
  3. [Table III caption] The caption says that 'the x-axis and y-axis represent the operation of the background and the device under test,' but the table is a static matrix without visible axes. Please add explicit row and column headers, and consider reporting absolute bandwidths as well as percentages.
  4. [§IV.A, RocksDB promotion] The explanation for RocksDB's performance improvement under CXL ld traffic relies on a 24% reduction in instruction count, but the text does not state how instructions were counted or whether this reduction was statistically significant across runs; please add measurement details.
  5. [§V.A] The sentence 'restricted to 100% (1/16 of the time originally occupied)' is confusing; please clarify whether 100% refers to a full CPU quota of one core and how the factor 1/16 is derived from 16 background threads.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: all central claims are direct measurements on real hardware, with independent counter cross-checks; cited prior work is context only.

full rationale

The paper is an empirical characterization study rather than a derivation chain. Its core claims (e.g., up to 93.2% MMEM bandwidth suppression under CXL ntst in Table III) are direct measurements of bandwidth and latency, not outputs of a model fit to those same measurements. The reported CXL bandwidth is cross-checked between an instruction-level tool (cxlMemTest from Sun et al.) and hardware CXL PMU counters, with the paper explicitly noting the two values agree (13169 MB/s vs 13342 MB/s); this is an independent validation, not a circular construction. The reverse-reasoning analysis (Insight #2, TOR congestion) is presented as a hypothesis supported by PMU counters (Table IV), and the paper performs additional experiments such as cache flushing and nop injection to test the promotion effect, so the causal story is not presupposed by the measurement methodology. Citations to prior CXL characterization works (Sun et al., Tang et al., Liu and Wang) are used for context, for the cxlMemTest tool, and for the claim that interference was previously unstudied; none of these citations is load-bearing for the paper's quantitative results. Although Tang et al. shares an author with this paper, it is cited only as prior device characterization that did not consider interference, so this is not a self-citation chain. The mitigation experiments in Section V are direct interventions (CPU quota restriction, frequency scaling, MBA) followed by measurement of recovery; reducing the interfering background traffic and observing reduced interference is the experiment itself, not a prediction equivalent to an input. The main identified risk in the paper is external validity across the two evaluated platforms, which is a correctness/generalization concern rather than circularity. Therefore the derivation chain is self-contained and no circular step is present.

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

This is an empirical measurement study with no formal model, so there are no free parameters fitted to data. The central claims instead rely on the representativeness of the two CXL hardware setups, the validity of the PMU counters used for reverse-reasoning analysis, and the representativeness of the chosen benchmark configurations. No new entities are postulated.

assumptions (4)
  • domain assumption The two test platforms' CXL topologies are representative of modern server designs: CXL expander on a separate NUMA node connected to Node 0 via PCIe.
    Section II-C and Figure 1 establish the topology; the paper generalizes its conclusions from this setup.
  • domain assumption Disabling hyperthreading and locking CPU frequency to 2 GHz provides a stable baseline for measuring bandwidth interference.
    Section III-A states these measures but does not quantify their effect on variance.
  • domain assumption The PMU counters (unc_cha_tor_occupancy.ia_miss, unc_cha_tor_inserts.ia_miss) and kernel hotspots correctly identify the interference mechanism.
    Section III-C uses these counters to infer TOR congestion; the inference relies on the counters being accurate and specifically caused by CXL traffic.
  • domain assumption The selected microbenchmark settings (FIO iodepth=16, block size 4KB; cxlMemTest thread sweeps) capture the range of real workload behavior.
    Section III-A parameterizes the benchmarks; the conclusions about interference magnitude assume these settings are representative.

how reviews work

0 comments
Cite this review

Pith. "Pith review of CXL-Interference: Analysis and Characterization in Modern Computer Systems." pith.science (2026). https://pith.science/paper/YBK6RRA4

@misc{pith2026241118308,
  author       = {Pith},
  title        = {Pith review of: CXL-Interference: Analysis and Characterization in Modern Computer Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YBK6RRA4}},
  note         = {Machine review of arXiv:2411.18308}
}
read the original abstract

Compute Express Link (CXL) is a promising technology that addresses memory and storage challenges. Despite its advantages, CXL faces performance threats from external interference when co-existing with current memory and storage systems. This interference is under-explored in existing research. To address this, we develop CXL-Interplay, systematically characterizing and analyzing interference from memory and storage systems. To the best of our knowledge, we are the first to characterize CXL interference on real CXL hardware. We also provide reverse-reasoning analysis with performance counters and kernel functions. In the end, we propose and evaluate mitigating solutions.

Figures

Figures reproduced from arXiv: 2411.18308 by the authors.

Figure 1
Figure 1. Schematic illustration of hardware setup [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Datapaths in filesystem, CXL and MMEM workloads. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Microbenchmark case studies The description of the selected applications is shown in Table V. The overview of the largest performance decline percentage evaluation result for each application is depicted in [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: CXL-related interference on real applications. The suffixes ”-A/B/C/D” indicate the type to which the experiment belongs. We use [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 6
Figure 6. Figure 6: The performance (trial time) of GAPBS benchmark in Type [PITH_FULL_IMAGE:figures/full_fig_p005_6.png]
Figure 5
Figure 5. Figure 5: The performance (operations per second) of RocksDB under [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 7
Figure 7. Figure 7: Bandwidth and latency of MMEM when applying different [PITH_FULL_IMAGE:figures/full_fig_p006_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

37 extracted references · 31 canonical work pages

  1. [1]

    Salus: Efficient security support for cxl-expanded gpu memory,

    R. Abdullah, H. Lee, H. Zhou, and A. Awad, “Salus: Efficient security support for cxl-expanded gpu memory,” in 2024 IEEE International Symposium on High-Performance Computer Architecture (HPCA), 2024, pp. 1–15

    work page 2024

  2. [2]

    AMD64 Technology Platform Quality of Service Extensions , Advanced Micro Devices, Inc., February 2022

    work page 2022

  3. [3]

    Flexible i/o tester,

    J. Axboe, “Flexible i/o tester,” 2022. [Online]. Available: https: //github.com/axboe/fio

    work page 2022

  4. [4]

    An analysis on compute express link with rich protocols and use cases for data centers,

    E. L. Bai and S. A. Raut, “An analysis on compute express link with rich protocols and use cases for data centers,” in International Conference on Image Processing and Capsule Networks. Springer, 2022, pp. 787–800

    work page 2022

  5. [5]

    Bakhvalov, Performance Analysis and Tuning on Modern CPUs: Squeeze the last bit of performance from your application

    D. Bakhvalov, Performance Analysis and Tuning on Modern CPUs: Squeeze the last bit of performance from your application. Indepen- dently published, 2020

    work page 2020

  6. [6]

    Characterizing i/o in machine learning with mlperf storage,

    O. Balmau, “Characterizing i/o in machine learning with mlperf storage,” ACM SIGMOD Record, vol. 51, no. 3, pp. 47–48, 2022

    work page 2022

  7. [7]

    The gap benchmark suite,

    S. Beamer, K. Asanovi ´c, and D. Patterson, “The gap benchmark suite,”

    work page

  8. [8]

    Compute express link specification,

    C. E. L. Consortium et al., “Compute express link specification,” 2020

    work page 2020

Show all 37 references
  1. [9]

    Cxl protocol hard ip functionality accelerates a wide range of data-centric workloads,

    I. Corporation, “Cxl protocol hard ip functionality accelerates a wide range of data-centric workloads,” https://www.intel.com/content/www/ us/en/products/details/fpga/intellectual-property/interface-protocols/cxl- ip.html

  2. [10]

    Intel ® resource director technology (intel ® rdt) framework,

    I. Corporation, “Intel ® resource director technology (intel ® rdt) framework,” https://www.intel.com/content/www/us/en/architecture- and-technology/resource-director-technology.html, 2015

    2015

  3. [11]

    Intel performance counter monitor,

    I. Corporation, “Intel performance counter monitor,” 2024, accessed: 2024-08-02. [Online]. Available: https://github.com/intel/pcm

    2024

  4. [12]

    Corporation, Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2B: Instruction Set Reference, M-U

    I. Corporation, Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2B: Instruction Set Reference, M-U. Intel Corporation, 2024

    2024

  5. [13]

    Ai and memory wall,

    A. Gholami, Z. Yao, S. Kim, C. Hooper, M. W. Mahoney, and K. Keutzer, “Ai and memory wall,” IEEE Micro, 2024

    2024

  6. [14]

    Heo, Control Groups v2 , 2015

    T. Heo, Control Groups v2 , 2015. [Online]. Available: https: //www.kernel.org/doc/Documentation/cgroup-v2.txt

    2015

  7. [15]

    4th Gen Intel ® Xeon® Scalable Processor XCC (Codename Sapphire Rapids) Uncore Performance - Monitoring Guide , Intel Corporation, April 2024

    2024

  8. [16]

    Memtis: Efficient memory tiering with dynamic page classification and page size determination,

    T. Lee, S. K. Monga, C. Min, and Y. I. Eom, “Memtis: Efficient memory tiering with dynamic page classification and page size determination,” in Proceedings of the 29th Symposium on Operating Systems Principles , 2023, pp. 17–34

    2023

  9. [17]

    Exploring and evaluating real-world cxl: Use cases and system adoption,

    J. Liu, X. Wang, J. Wu, S. Yang, J. Ren, B. Shankar, and D. Li, “Exploring and evaluating real-world cxl: Use cases and system adoption,” 2024. [Online]. Available: https://arxiv.org/abs/2405.14209

    2024

  10. [18]

    Cz120 memory expansion module,

    MICRON, “Cz120 memory expansion module,” https://www.micron. com/products/memory/cxl-memory

  11. [19]

    Sk hynix introduces industry’s first cxl- based computational memory solution (cms) at the ocp global sum- mit,

    S. H. NEWSROOM, “Sk hynix introduces industry’s first cxl- based computational memory solution (cms) at the ocp global sum- mit,” https://news.skhynix.com/sk-hynix-introduces-industrys-first-cxl- based-cms-at-the-ocp-global-summit/, 2022

    2022

  12. [20]

    Dracksim: Simulating cxl-enabled large-scale disaggre- gated memory systems,

    A. Puri, K. Bellamkonda, K. Narreddy, J. Jose, V. Tamarapalli, and V. Narayanan, “Dracksim: Simulating cxl-enabled large-scale disaggre- gated memory systems,” in Proceedings of the 38th ACM SIGSIM Conference on Principles of Advanced Discrete Simulation , 2024, pp. 3–14

    2024

  13. [21]

    Extending intel-x86 consistency and persistency: formalising the semantics of intel-x86 memory types and non-temporal stores,

    A. Raad, L. Maranget, and V. Vafeiadis, “Extending intel-x86 consistency and persistency: formalising the semantics of intel-x86 memory types and non-temporal stores,” Proc. ACM Program. Lang., vol. 6, no. POPL, jan 2022. [Online]. Available: https: //doi.org/10.1145/3498683

    2022 doi

  14. [22]

    Hint: Designing cache-efficient mpi alltoall using hybrid memory copy ordering and non-temporal instructions,

    B. Ramesh, N. Contini, N. Alnaasan, K. K. Suresh, M. Abduljabbar, A. Shafi, H. Subramoni, and D. K. D K Panda, “Hint: Designing cache-efficient mpi alltoall using hybrid memory copy ordering and non-temporal instructions,” in 2024 IEEE International Parallel and Distributed Pr...

    2024

  15. [23]

    System optimization of data analytics platforms using compute express link (cxl) memory,

    S. Ryu, S. Kim, J. Jun, D. Moon, K. Lee, J. Choi, S. Kim, H. Kim, L. Kim, W. H. Choi, M. Nam, D. Hwang, H. Roh, and Y. Joo, “System optimization of data analytics platforms using compute express link (cxl) memory,” in 2023 IEEE International Conference on Big Data and Smart Co...

    2023

  16. [24]

    Sanfilippo, “Redis,” 2009

    S. Sanfilippo, “Redis,” 2009. [Online]. Available: https://redis.io/

    2009

  17. [25]

    Samsung develops industry’s first cxl dram sup- porting cxl 2.0,

    S. Semiconductor, “Samsung develops industry’s first cxl dram sup- porting cxl 2.0,” https://semiconductor.samsung.com/news-events/news/ samsung-develops-industrys-first-cxl-dram-supporting-cxl-2-0/, 2022

    2022

  18. [26]

    Novel composable and scaleout architectures using compute express link,

    D. D. Sharma, “Novel composable and scaleout architectures using compute express link,” IEEE Micro, vol. 43, no. 2, pp. 9–19, 2023

    2023

  19. [27]

    Lightweight frequency- based tiering for cxl memory systems,

    K. Song, J. Yang, S. Liu, and G. Pekhimenko, “Lightweight frequency- based tiering for cxl memory systems,”arXiv preprint arXiv:2312.04789, 2023

    2023 arXiv

  20. [28]

    Demystifying 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, “Demystifying cxl memory with genuine cxl-ready systems and devices,” in Proceedings of the 56th Annual IEEE/ACM International Symposium on Micro...

    2023

  21. [29]

    Exploring performance and cost optimization with asic-based cxl memory,

    Y. Tang, P. Zhou, W. Zhang, H. Hu, Q. Yang, H. Xiang, T. Liu, J. Shan, R. Huang, C. Zhao et al., “Exploring performance and cost optimization with asic-based cxl memory,” in Proceedings of the Nineteenth European Conference on Computer Systems , 2024, pp. 818–833

    2024

  22. [30]

    A persistent key-value store for fast storage environments,

    F. R. team, “A persistent key-value store for fast storage environments,” https://rocksdb.org/, 2024

    2024

  23. [31]

    Cxl memory expander controller (mxc),

    M. Technology, “Cxl memory expander controller (mxc),” https://www. montage-tech.com/MXC

  24. [32]

    Filebench: A flexible framework for file system benchmark- ing.; login,

    T. Vasily, “Filebench: A flexible framework for file system benchmark- ing.; login,” The USENIX Magazine , vol. 41, p. 6, 2016

    2016

  25. [33]

    Cxlmemsim: A pure software simulated cxl. mem for performance characterization,

    Y. Yang, P. Safayenikoo, J. Ma, T. A. Khan, and A. Quinn, “Cxlmemsim: A pure software simulated cxl. mem for performance characterization,” arXiv preprint arXiv:2303.06153, 2023

    2023 arXiv

  26. [34]

    {MTˆ 2 }: Memory bandwidth regulation on hybrid {NVM/DRAM} platforms,

    J. Yi, B. Dong, M. Dong, R. Tong, and H. Chen, “ {MTˆ 2 }: Memory bandwidth regulation on hybrid {NVM/DRAM} platforms,” in 20th USENIX Conference on File and Storage Technologies (FAST 22), 2022, pp. 199–216

    2022

  27. [35]

    Tinyllama: An open-source small language model,

    P. Zhang, G. Zeng, T. Wang, and W. Lu, “Tinyllama: An open-source small language model,” 2024

    2024

  28. [36]

    Managing memory tiers with cxl in virtualized environments,

    Y. Zhong, D. S. Berger, C. Waldspurger, I. Agarwal, R. Agarwal, F. Hady, K. Kumar, M. D. Hill, M. Chowdhury, and A. Cidon, “Managing memory tiers with cxl in virtualized environments,” in Symposium on Operating Systems Design and Implementation , 2024. 8

    2024

  29. [2017]

    Available: https://arxiv.org/abs/1508.03619

    [Online]. Available: https://arxiv.org/abs/1508.03619

    arXiv

Pith tools

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