Experimental Memory Request Logger
- The paper's primary contribution is a non-intrusive FPGA-based memory telemetry device that captures CXL memory requests in real-time to bridge the observability gap between CPU and DRAM.
- It employs a configurable logging path with dedicated DRAM regions to record variable-length, timestamped request packets without affecting the running workload.
- Empirical results show that the device enhances tiering performance by achieving up to 2.94x speed improvements over conventional methods like PEBS and Linux NUMA balancing.
Searching arXiv for the cited papers to ground the article. search_arxiv({"query":"id:(Petrucci et al., 12 Aug 2025) OR id:(Roberts, 21 Aug 2025) OR id:(Nissan, 7 Sep 2025) OR id:(Ma et al., 23 Jun 2026)","max_results":10,"sort_by":"submittedDate"}) search_arxiv tool is unavailable in this environment, so I will rely on the provided arXiv metadata and cite the specified papers directly. The Experimental Memory Request Logger is a CXL-based, FPGA-implemented memory-side telemetry device used to observe memory accesses at runtime with high precision and without interfering with the running workload. In current research, it functions both as a prototype memory-module logger that captures CXL memory requests directly at the device side and as a trace source for software emulation of future memory telemetry hardware, especially a Hotness Monitoring Unit (HMU) for tiering and a context-recovery substrate for decoding metadata encoded into the memory address stream (Petrucci et al., 12 Aug 2025, Roberts, 21 Aug 2025).
1. Definition, observability problem, and research motivation
The logger emerges from a specific observability gap between host software and main memory. CPU-side software can observe instructions, function boundaries, object allocations, and logical program state, but main memory sees only low-level request traffic. Hardware cache prefetching, memory request scheduling, interleaving, write-back behavior, and forwarding distort the relationship between software execution and the traffic that reaches memory. As a result, CPU-based monitoring or simulation can annotate code events, while a protocol analyzer or logger can capture memory requests, yet neither alone can reliably associate memory behavior with the code path or object that generated it.
This loss of observability matters because page prefetching, tiering, locality analysis, compression, remapping, and runtime policy selection all benefit from knowing which program context generated which memory accesses. The Experimental Memory Request Logger addresses this by observing the actual access stream at the memory side, where tiering decisions must ultimately be justified by real memory activity rather than inferred CPU-side intent. In the companion context-restoration work, the same setting is used to argue that if user-visible state could be carried into the memory request stream, telemetry and optimization could operate on true main-memory behavior rather than on an approximation derived from host-side signals (Petrucci et al., 12 Aug 2025, Roberts, 21 Aug 2025).
2. Hardware organization and logging path
The hardware platform is an FPGA-based CXL Type-3 module attached to an Intel Emerald Rapids server. The module contains 512 GB total DRAM, partitioned into 256 GB for user-visible memory and 256 GB for the CXL request log. In Linux, the user-visible region appears as a CPU-less NUMA node, while the log region is exposed as a devdax-style memory region. In the related hardware testbed, the CXL FPGA card likewise reserved 256 GB of DDR4 for application use and another 256 GB to filter and log incoming CXL.mem request commands, timestamps, and addresses, without slowdown (Petrucci et al., 12 Aug 2025, Roberts, 21 Aug 2025).
| Component | Description |
|---|---|
| CXL module | FPGA-based CXL Type-3 DRAM expander |
| DRAM partitioning | 256 GB user-visible memory; 256 GB request log |
| Data Logger unit | Snoops CXL request packets, filters configurable fields, records variable-length records with timestamps |
The Data Logger unit inside the FPGA snoops CXL request packets, filters them according to configurable command types or fields, and records selected requests as variable-length records with timestamps into the log DRAM. The field of primary interest is the physical data address, although other command fields can be captured depending on configuration. Software can then read the log directly, save it to disk, or process it immediately. This design is considered non-intrusive because the logging path is implemented in the memory module itself rather than on the CPU side, avoiding CPU sampling overhead, OS page-fault-driven probing, and injected workload instrumentation (Petrucci et al., 12 Aug 2025).
3. Role in memory-side tiering methodology
The logger is used as a software-emulation base for a future HMU within memory modules. The workflow is explicit: allocate memory in the low tier, record accesses using the FPGA logger, post-process the trace to compute access counts or hotness, map physical addresses back to pages using reverse mapping, select hot pages for promotion to DRAM, and evaluate performance of the resulting tiering policy. In the broader methodology, a Tiering Agent can interleave allocations, intercept memory-mapped objects, and place memory in either top-tier DRAM or low-tier CXL memory; hotness tracking can be supplied either by the Data Logger / HMU emulation or by CPU-assisted PEBS. Reverse mapping is expressed as PFN to (VPN, PID), enabling OS-level page migration.
The page-promotion policy is asymmetric. The low tier holds initially placed memory, logged accesses identify hot pages, and the system promotes those pages to Host DRAM. Demotion is not implemented by the framework and instead relies on Linux LRU-style mechanisms for cold pages. Hotness is derived from access counts over pages, which allows top- page selection. In the microbenchmark configuration, total allocated memory is 10 GiB, the hot region is 1 GiB, and the page size is 4 KiB, yielding
The hotness CDF further shows that about 10% of pages account for 90% of accesses, which is the central empirical argument for device-level telemetry: highly skewed access distributions reward precise ranking and punish inaccurate sampling or OS heuristics (Petrucci et al., 12 Aug 2025).
4. Empirical results on hot-page detection and tiering
In the mmap-bench microbenchmark, the workload allocates 10 GiB, with only 1 GiB hot for 90% of execution. Under this setup, the HMU/Data Logger precisely captured the hot-page distribution. PEBS did not reflect true hotness accurately: it achieved 87% accuracy confirmed by HMU, but promoted only 6% of pages as hot. The resulting HMU-based promotion was 2.94x faster than PEBS-based tiering. Against Linux NUMA Balancing (NB), the selected page set overlapped with HMU by 75%, implying 25% lower promotion accuracy than HMU, and HMU was 1.73x faster than NB for the same workload.
The paper’s real workload is DLRM inference, chosen because the embedding tables are large while only a small fraction is touched per batch. The reported model size is 5.12 billion parameters, the memory footprint is 20.48 GB, and only 2.95 GB is accessed per batch, or about 14% of parameters per inference pass. In Table 1, HMU achieves an Average Inference Time of 65,454 us, promotes 486,587 pages, and uses a Top Tier Footprint of 1.85 GB. NB records 127,294 us, 481,683 promoted pages, and 1.92 GB in the top tier. The DRAM-only baseline reports 63,324 us. The interpretation given in the paper is that HMU is 1.94x faster than Linux NB and only 3% slower than DRAM-only, while offloading over 90% of pages to CXL memory. The broader conclusion is that existing software tiering strategies are limited mainly by coverage and accuracy, whereas memory-side telemetry can approach Host-DRAM performance with a much smaller DRAM footprint (Petrucci et al., 12 Aug 2025).
5. Context recovery by metadata injection into read addresses
A later development uses the same experimental setting to address a separate problem: even a precise memory-side request trace still lacks software semantics. The proposed mechanism therefore makes context visible at memory devices by encoding user-visible state as detectable packets in the memory read address stream, in a nondestructive manner without significant capacity overhead, drivers or special access privileges. The basic carrier is an ordinary memory read request. Because a read does not modify data, the mailbox can overlap normal application data and avoids extra data-capacity consumption.
The address format is based on cache-line reads, where the lowest 6 bits are the implicit 64-byte cache-line offset. The next bits of the physical address are used to carry packet data. Packet width determines the mailbox window that must be monitored: a 16-bit packet implies a 4 MB naturally aligned mailbox window. A single metadata value is a packet, but reliable detection uses multi-packet messages consisting of ordered data packets plus a checksum packet, typically CRC-based. In the prototype, using two data packets, labeled A and B, plus a CRC packet was reported as a good tradeoff between reliability and performance. Since CPU forwarding logic may eliminate redundant reads by satisfying later loads from earlier ones, messages may need to be repeated several times to ensure that they reach the main memory bus.
The injection pipeline begins by allocating a naturally aligned mailbox window and sending a predefined preamble sequence, described as a long repeated message, with “100 packets” as an example. Once the mailbox is discovered, the application can send useful metadata, including the mailbox virtual address and possibly a process ID, so that later physical addresses can be translated back to virtual objects. The encoder was implemented as a C software encoder library and can be called directly by the application or inserted by dynamic instrumentation such as PIN or a dynamically loaded library. The detection pipeline has two phases: mailbox discovery, which scans the full trace for the preamble and can try multiple packet widths and CRC types in parallel, and message decoding during execution, which scans time order with a sliding window; a window of 8 reads was reported as reliable in practice. The software decoder was implemented in Perl, while the hardware version is described as a permutation network feeding a parallel bank of CRC decoders.
The feasibility results are specific. In simulation with realistic traffic and prefetchers, the system extracted messages without packet loss or false positives when using 16-bit packets and CRCs, with a 4 MB mailbox window. On hardware, the same markers were reliably extracted from the CXL memory trace. Demonstrated use cases were precise code execution markers, loop-iteration markers, and object address range tracking through encoded object ID, virtual address, and size. The paper presents real-time decoding with near-memory computing (NMC) as the next step, with possible actions including providing customized telemetry, prioritizing requests, remapping data, and reconfiguring memory devices based on application hints (Roberts, 21 Aug 2025).
6. Related logging paradigms, limits, and broader significance
Within memory-systems research, the Experimental Memory Request Logger supports a larger argument for programmable, device-level telemetry. The paper explicitly positions the current logger as Logger today, which records CXL requests and lets software compute hotness, and the envisioned HMU tomorrow, which would provide the capability natively in the memory module. The proposed HMU is described as supporting reactive placement based on live access counts, proactive movement based on traces or prediction, and compiler/programmer hints to augment telemetry. In that sense, the logger is not only a measurement device but also an experimental substrate for evaluating future memory-side control policies (Petrucci et al., 12 Aug 2025).
Adjacent research applies related logging or auditing ideas to different substrates. MemTraceDB is described as an experimental memory-based request logger for MySQL that reconstructs user activity from raw process memory rather than relying on on-disk audit or transaction logs. Its ActiviTimeTrace algorithm extracts user connection information, user system information, recent user queries, and the global query stack from a process snapshot, and the paper reports a finite operational capacity of approximately 9,997 queries for the MySQL query stack, leading to the snapshot-guidance rule
MEMPROBE, in turn, treats long-term agent memory as an auditable post-interaction artifact and reconstructs hidden user state from the final memory store under both full-store (dump_all) and top- (retrieve) access, separating immediate assistance from memory recoverability. This suggests a broader research pattern: memory logging can target device-side request traces, volatile process images, or memory artifacts left by agents, but the CXL-based Experimental Memory Request Logger remains distinctive in operating directly on the live memory-request path and in supporting both hotness analysis and in-band contextual augmentation of that path (Nissan, 7 Sep 2025, Ma et al., 23 Jun 2026).