Hotness Monitoring Unit (HMU)

Updated 8 July 2026

Hotness Monitoring Unit (HMU) is a system that identifies and tracks hot data in memory through dedicated hardware telemetry or software heuristics.
It enhances page placement by providing precise live data access metrics, leading to improved performance in tiered memory architectures.
Applications span CXL-based memory tiering, mobile compressed swap management, and thermal monitoring in experimental setups.

Searching arXiv for the cited HMU-related papers to ground the article in current preprints. The Hotness Monitoring Unit (HMU) is a term used in multiple technically distinct but conceptually related senses across recent arXiv literature. In its most explicit use, it denotes a memory-side hardware mechanism that monitors which data pages are actually hot at runtime, so that a tiered memory system can make better page placement and migration decisions (Petrucci et al., 12 Aug 2025). More broadly, several papers describe functionally equivalent mechanisms that estimate, classify, or reconstruct “hotness” in other domains, including mobile compressed swap, cryogenic housekeeping, thermal mapping, MPSoC temperature estimation, retrieval-augmented generation, and thermo-fluidic digital twins (Liang et al., 18 Feb 2025, Tartakovsky et al., 12 May 2025, Lee et al., 2022, Glocker et al., 2014, Ge et al., 23 Oct 2025, Toolhally et al., 5 Nov 2025). Across these settings, an HMU is best understood as a monitoring-and-decision substrate that identifies states or objects with elevated operational importance—hot pages, hot anonymous data, hot KV chunks, or thermal hot spots—and provides that information to downstream placement, control, or estimation logic.

1. Core concept and definitional scope

In "A Limits Study of Memory-side Tiering Telemetry" the HMU is the authors’ name for a memory-assisted hot-page tracking mechanism embedded in or associated with the memory module (Petrucci et al., 12 Aug 2025). Its purpose is to observe accesses to memory-resident data directly at the device side and identify the pages that deserve promotion into the faster tier. The paper contrasts three families of page promotion strategies: OS-level Linux NUMA balancing, CPU-assisted sampling such as Intel PEBS-based sampling, and memory-assisted monitoring by an HMU within memory modules. The HMU can “directly track all relevant hot pages within each monitoring range at the hardware level.” In that formulation, the term refers specifically to device-level telemetry for host-local DRAM and CXL-attached memory.

Other papers use different names while serving a similar functional role. "Ariadne: A Hotness-Aware and Size-Adaptive Compressed Swap Technique for Fast Application Relaunch and Reduced CPU Usage on Mobile Devices" can be read as a software analogue of an HMU because it builds a low-overhead hotness-estimation and hotness-aware placement pipeline around compressed swap (Liang et al., 18 Feb 2025). " $\tau$ HK: a modular housekeeping system for cryostats and balloon payloads" is presented as a housekeeping system, but functionally maps closely to an HMU for experimental hardware because it combines temperature sensing, thermal state monitoring, heater actuation, and telemetry integration (Tartakovsky et al., 12 May 2025). "Emulated ASIC Power and Temperature Monitor System for FPGA Prototyping of an Invasive MPSoC Computing Architecture" does not use the HMU label, but its TPMon temperature-monitoring path is functionally very close to an HMU because it estimates the thermal state of processing elements online and provides hotness information to runtime management (Glocker et al., 2014).

A broader reading appears in "HA-RAG: Hotness-Aware RAG Acceleration via Mixed Precision and Data Placement," where the closest HMU-equivalent is the combination of access-frequency statistics collection, sorted hotness ranking over KV chunks, and policy modules for mixed-precision compression and data placement (Ge et al., 23 Oct 2025). In "A Digital Twin of Evaporative Thermo-Fluidic Process in Fixation Unit of DoD Inkjet Printers," the HMU role is realized by an infinite-dimensional state estimator that reconstructs a distributed thermo-fluidic hotness field from sparse measurements (Toolhally et al., 5 Nov 2025). This suggests that, across domains, HMU denotes either a dedicated hardware monitor or an estimation-and-control layer whose common task is to expose operationally significant hotness states to system-level decision mechanisms.

2. Memory-tiering HMU in CXL-based systems

The most explicit HMU formulation appears in CXL-based memory tiering. The target system consists of host-local DRAM as the fast tier and CXL-attached memory as the slower, larger-capacity tier (Petrucci et al., 12 Aug 2025). The paper argues that memory tiering only works well if the system can identify truly hot pages accurately and with broad coverage. Existing host-side approaches are described as limited in coverage and accuracy, and the study makes a case for programmable, device-level telemetry as a scalable and efficient solution for future memory systems.

The implementation context is a CXL-based Experimental Memory Request Logger that reveals precise memory access patterns at runtime without interfering with running workloads. The authors use it for software emulation of future memory telemetry hardware (Petrucci et al., 12 Aug 2025). In this setting, the HMU resides within memory modules and contributes three kinds of information flow: reactive placement based on data address monitoring, proactive data movement, and compiler hints. The paper presents these as complementary to memory-side hotness observation rather than substitutes for it.

The reported benefit is tied directly to page-placement quality. Analysis of page placement using profiled access counts on a Deep Learning Recommendation Model (DLRM) indicates a potential 1.94x speedup over Linux NUMA balancing tiering, and only a 3% slowdown compared to Host-DRAM allocation while offloading over 90% of pages to CXL memory (Petrucci et al., 12 Aug 2025). These figures are used to argue that an HMU capable of directly observing hot pages at the hardware level can materially improve promotion and migration policies in tiered memory.

This memory-side interpretation is narrower than several of the other HMU-like systems, but it establishes the most literal definition: a hardware telemetry unit close to the memory device, exporting hotness for page placement. A plausible implication is that this definition provides the reference point against which the other software and estimation-based HMU analogues can be understood.

3. Software hotness monitoring and classification in mobile memory systems

In mobile memory management, Ariadne provides an HMU-like design specialized for anonymous memory under DRAM pressure (Liang et al., 18 Feb 2025). The paper argues that Android’s default compressed swap stack—primarily ZRAM, optionally extended with ZSWAP—does not differentiate between hot and cold data or leverage different compression chunk sizes and data locality. Ariadne therefore introduces a low-overhead hotness-aware organization pipeline, referred to as HotnessOrg, together with AdaptiveComp and PreDecomp.

Ariadne defines three hotness classes precisely in terms of future use relative to relaunch behavior:

Hot data: data used during application relaunch
Warm data: data potentially used during application execution after relaunch
Cold data: data usually not used again (Liang et al., 18 Feb 2025)

The key predictor is that the hot data of the most recent relaunch is a good predictor of the hot data of the next relaunch. The trace study reports Hot Data Similarity between consecutive relaunches averaging 70%, and Reused Data—the fraction of hot data from relaunch $i$ that reappears as hot or warm in relaunch $i+1$ —averaging 98% (Liang et al., 18 Feb 2025). Ariadne does not add a hardware monitor or sampled access-bit scanner; instead, it piggybacks on existing OS events. Application relaunch accesses identify hot pages, normal runtime accesses to cold-list pages identify warm pages, and existing LRU list machinery in Linux/Android is reused for page organization.

The operational representation is simple. Within each application, Ariadne maintains three LRU lists—hot, warm, and cold—and updates them at two cadences: per relaunch and per page access during execution (Liang et al., 18 Feb 2025). The mechanism does not physically move data to classify hotness; it manipulates list membership. The paper states that list operations are negligible because an LRU operation is “much faster (e.g., $100\times$ ) than swapping.”

Hotness then drives concrete downstream actions. Hot data are kept uncompressed in DRAM if possible, warm data are kept compressed in zpool, and cold data can be written compressed to flash-backed swap space (Liang et al., 18 Feb 2025). Compression granularity is also hotness-sensitive: hot-list chunks use 256 B, 512 B, or 1 KB, warm-list chunks use 2 KB or 4 KB, and cold-list chunks use 16 KB or 32 KB, with sensitivity experiments up to 64 KB for cold data. Proactive decompression uses a locality-based one-page lookahead because the probability of 2 consecutive pages accessed is 0.61–0.86, whereas the probability of 4 consecutive pages accessed is 0.33–0.72.

The evaluation reports that Ariadne reduces application relaunch latency by about 50% on average and reduces CPU usage of compression/decompression by about 15% on average compared with baseline ZRAM (Liang et al., 18 Feb 2025). The paper also reports approximately 70% average Coverage and approximately 92% average Accuracy for hot-data identification. This makes Ariadne a clear example of an HMU-like software monitor: its hotness state is coarser and more heuristic than device-level access counters, but it feeds placement, reclaim, chunk sizing, and speculative decompression in essentially the same way.