---
title: Experimental Memory Request Logger
url: https://www.emergentmind.com/topics/experimental-memory-request-logger
type: topic
---

# Experimental Memory Request Logger

Searching arXiv for the cited papers to ground the article.
search_arxiv({"query":"id:2508.09351 OR id:2510.15878 OR id:2509.05891 OR id:2606.24595","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 [2508.09351][2510.15878].

## 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 [2508.09351][2510.15878].

## 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** [2508.09351][2510.15878].

| 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 [2508.09351].

## 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-\(K\) 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
$$
K = \frac{1\ \text{GiB}}{4\ \text{KiB}} = 262{,}144.
$$
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 [2508.09351].

## 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 \(K\)** 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 [2508.09351].

## 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 [2510.15878].

## 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 [2508.09351].

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
$$
t_{\text{snapshot}} = \frac{9997}{3n}.
$$
**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-\(k\) (`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 [2509.05891][2606.24595].

Source: https://www.emergentmind.com/topics/experimental-memory-request-logger