A Working Model of the Telemetry Gap

CXL capacity exposure and runtime memory telemetry are two different loops that must work together. Linux can describe a CXL region, attach it to a NUMA and memory-tier model, and make it usable through DAX or the page allocator. NEMO addresses what happens afterward: how the system learns which requests are important enough to move, split, or control. Bringing those loops together gives readers a practical test for the design—whether a signal is complete, timely, sufficiently precise, policy-defined, and cheap enough to use continuously.

Two loops, one system

The first loop is a capacity and topology loop. Firmware and ACPI describe address ranges and locality. Linux turns those descriptions into CXL objects, decoder associations, NUMA nodes, and a memory-tier view. DAX and memory hotplug then determine whether the region remains a device-like resource or becomes ordinary memory that the page allocator can use. The loop succeeds when Linux knows what resource exists, where it is located, how it can be reached, and which component owns each transition.

The second loop is behavioral. Applications and the kernel issue memory requests. Those requests encounter a hierarchy in which local DRAM and CXL-attached memory can have different service characteristics. A policy observes some representation of the requests, decides which pages or tenants matter, and changes placement, page size, or resource allocation. The action changes the next set of requests and therefore the next observation. This loop succeeds only when the signal is about the behavior that the policy can actually change.

The loops meet at the memory controller, but they are not the same operation. A decoder can route an address correctly without telling the OS whether that address is hot. A page can be online in a CXL-backed NUMA node while the policy still has no useful evidence about how often it is accessed. Conversely, a detailed access count cannot make an offline region available to the page allocator or repair a bad topology description. The first loop establishes legal, addressable resources; the second makes decisions about their use.

flowchart LR F["Firmware and Linux configuration"] --> T["CXL-visible memory tier"] T --> R["Application and kernel requests"] R --> O["Controller-side observation"] O --> S["OS-defined telemetry state"] S --> P["Placement, splitting, or isolation policy"] P --> R P --> Q["Latency, throughput, and isolation outcome"]

This distinction changes how NEMO should be evaluated. It is not competing with Linux's CXL driver for the job of exposing capacity. It is competing with ways of learning what the exposed capacity is doing. Its proposed location is useful because the memory controller sees requests after software sampling choices have already hidden some events, but before the system has collapsed the traffic into a coarse outcome such as total socket bandwidth.

The location alone is not enough. A controller sees a high-rate stream, while a policy needs a meaningful unit: a huge page, a base page inside that huge page, or a tenant owning many pages. The central design question is how to preserve the controller's coverage while letting the OS choose the grouping that gives the next action meaning.