Data Movement Manager (DMM)

• Data Movement Manager (DMM) is a control mechanism that coordinates data transfers based on policy, ensuring correctness and suppressing redundant movement across diverse system layers.
• It employs techniques ranging from static analysis in compiler-driven OpenMP offload to dynamic LP-based bandwidth allocation in WAN transfers, optimizing resource usage.
• DMM implementations, including distributed DMA and adaptive hardware engines, enhance performance and fairness by tailoring data movement to workload and substrate-specific constraints.

Searching arXiv for the cited DMM-related papers to ground the article in current research. arXiv search query: "(Marzen et al., 2024) OR (Arora et al., 1 Aug 2025) OR (Deng et al., 19 Dec 2025) OR (Giannoula et al., 2023)" Data Movement Manager (DMM) denotes a class of mechanisms that coordinate data transfer so that computation can proceed with correct data visibility and improved resource utilization. In recent arXiv literature, the term spans at least four technical settings: compiler-driven host–device data mapping for OpenMP offload, a service that bridges CERN’s Rucio with ESnet’s SENSE and FTS for SDN-enabled bulk transfers, a distributed DMA architecture for point-to-multipoint movement on SoCs, and hardware support for data migration in disaggregated memory systems. Across these settings, a DMM is defined less by a single implementation pattern than by a recurring objective: infer or decide when, where, and how much data should move, while suppressing redundant movement and respecting correctness, bandwidth, latency, or topology constraints (Marzen et al., 2024, Arora et al., 1 Aug 2025, Deng et al., 19 Dec 2025, Giannoula et al., 2023).

1. Terminological scope and representative realizations

The literature uses “Data Movement Manager” to describe systems at markedly different layers of the stack. In OpenMP offload, the DMM function is exemplified by OMPDart, which models host–device data dependencies and emits target data, map, update, and firstprivate directives. In wide-area scientific data management, DMM is a Python-based, daemon-driven service that bridges Rucio, SENSE, FTS, and a monitoring stack. In SoC design, the DMM role is implemented as distributed DMA endpoints that realize point-to-multipoint transfer through logical chains. In disaggregated systems, DaeMon distributes data-movement logic across compute and memory engines and combines bandwidth partitioning, compression, and adaptive granularity selection (Marzen et al., 2024, Arora et al., 1 Aug 2025, Deng et al., 19 Dec 2025, Giannoula et al., 2023).

Context	Representative system	Core mechanism
Heterogeneous OpenMP offload	OMPDart	Static analysis and source-to-source insertion of OpenMP data mappings
Worldwide LHC Computing Grid transfers	DMM for the SENSE-Rucio Interoperation Prototype	Daemons, REST API, SQL state DB, LP-based bandwidth allocation
SoC point-to-multipoint movement	Torrent	Distributed DMA with Chainwrite over ordinary P2P NoC links
Disaggregated memory	DaeMon	Endpoint engines with bandwidth partitioning, compression, and multi-granularity movement

This breadth makes the term polysemous. A common misconception is that a DMM is necessarily a network orchestration service or, conversely, necessarily a compiler pass. The current literature shows that it may instead be a program analysis, a control-plane service, an endpoint DMA architecture, or a hardware-transparent migration substrate. This suggests that the unifying concept is policy-governed data-motion control rather than any particular software or hardware boundary.

2. Compiler-managed host–device mapping in OpenMP offload

For heterogeneous OpenMP, the central problem is that programmers must explicitly map data between the host and connected accelerator devices and reason about data validity and lifetime across multiple data environments. OMPDart formalizes this with a set of variables $V$, memory environments $\mathcal{E}=\{H,D\}$, and a Boolean validity predicate

$\mathrm{Valid}_e(v,p)\in\{0,1\},$

where $\mathrm{Valid}_e(v,p)=1$ iff the most recent write to $v$ up to program point $p$ occurred in environment $e$. A true dependence occurs exactly when code in environment $e$ reads $v$ at a point where $\mathrm{Valid}_e(v,p)=0$; anti/WAR and output/WAW dependencies do not require movement for correctness (Marzen et al., 2024).

OMPDart performs a flow- and context-sensitive, interprocedural data-flow analysis over a hybrid AST–CFG representation. It parses the source with Clang, constructs a CFG per function, links CFG nodes to AST subtrees, and computes interprocedural side-effect summaries

$\mathcal{E}=\{H,D\}$0

The forward traversal initializes $\mathcal{E}=\{H,D\}$1 and $\mathcal{E}=\{H,D\}$2, determines a minimal enclosing target data region around kernels, and records a required movement whenever a read observes invalid data in its current environment. The reported complexity is $\mathcal{E}=\{H,D\}$3 per function, where $\mathcal{E}=\{H,D\}$4 is the number of CFG nodes and $\mathcal{E}=\{H,D\}$5; the interprocedural summary fix-point converges in $\mathcal{E}=\{H,D\}$6, in practice linear.

The transformation rules are explicitly source-level. A single #pragma omp target data map(...) region is inserted around the sequence of kernels in each function to maximize reuse. Read-only scalars are handled with firstprivate(v), other transfers to device use map(to:v[range]), and transfers back to host are emitted as #pragma omp target update from(v[range]) at the precise CFG location before a host read. When possible, multiple update directives at the same program point are coalesced. To reduce transfer volume further, the analysis extracts loop bounds and subscript expressions to infer minimal array subranges, using the rule that an access of the form $\mathcal{E}=\{H,D\}$7 with $\mathcal{E}=\{H,D\}$8 transfers only $\mathcal{E}=\{H,D\}$9.

The optimization target is expressed as

$\mathrm{Valid}_e(v,p)\in\{0,1\},$0

with transfer reduction defined by

$\mathrm{Valid}_e(v,p)\in\{0,1\},$1

On nine benchmarks from Rodinia and HeCBench, the reported geometric-mean results are a 2.1 GB reduction in data transfer and a 2.8× speedup in end-to-end runtime relative to Implicit, and a 1.05× geometric-mean speedup plus an average 5.1× improvement in data-transfer time relative to Expert. In LULESH, which has 65 mapped variables and 15 kernels, the expert version contained multiple redundant update calls; the DMM achieved an 85% reduction in bytes moved and a 1.6× runtime speedup over the expert version. These results position the DMM as a correctness-preserving static optimizer whose main leverage comes from lifetime tracking and redundancy elimination rather than from changing kernel computation.

3. Priority-aware orchestration for wide-area scientific data transfer

In the SENSE–Rucio prototype, the DMM is a Python-based, daemon-driven service whose stated purpose is to bridge CERN’s Rucio data-management system with ESnet’s SENSE SDN service while interfacing with FTS and a monitoring stack. Architecturally, it comprises cooperating daemons, a small REST API server, and a lightweight SQL database that maintain end-to-end flow state. DMM periodically polls Rucio via the official Python client, discovers newly created point-to-point transfer rules, fetches rule metadata, and returns preallocated SENSE endpoints when Rucio calls QUERY_DMM(rule_id) prior to FTS submission. On the SDN side it invokes listEndpoints, selects free endpoints, computes per-flow bandwidth, provisions circuits, updates circuit bandwidth when priorities change, and tears down or downgrades circuits when rules finish. On the transfer side it continuously queries the FTS REST API for in-flight jobs, failures, retries, per-file latencies, and throughputs, then issues setRuleConcurrency(rule_id, N_j) using a simple analytic model of TCP in which bandwidth is proportional to concurrency divided by RTT (Arora et al., 1 Aug 2025).

Bandwidth allocation is formulated as a linear program over a global transfer-topology graph rebuilt whenever a rule enters the ALLOCATED state. The nodes are sites, the edges are merged source→dest pairs, the edge weights are sums of priorities, and the decision variable $\mathrm{Valid}_e(v,p)\in\{0,1\},$2 is the bandwidth assigned to edge $\mathrm{Valid}_e(v,p)\in\{0,1\},$3:

$\mathrm{Valid}_e(v,p)\in\{0,1\},$4

subject to

$\mathrm{Valid}_e(v,p)\in\{0,1\},$5

Here, $\mathrm{Valid}_e(v,p)\in\{0,1\},$6 is the node–edge incidence matrix, $\mathrm{Valid}_e(v,p)\in\{0,1\},$7 is the vector of port capacities, $\mathrm{Valid}_e(v,p)\in\{0,1\},$8 is the vector of merged priorities, and $\mathrm{Valid}_e(v,p)\in\{0,1\},$9 is a user-defined lower bound so that no flow gets completely starved. In the paper’s toy example, the solver returns $\mathrm{Valid}_e(v,p)=1$0, after which DMM unpacks each merged edge back into individual rules in proportion to their original priorities.

Monitoring is explicitly two-level. At the host level, Prometheus scrapes Node Exporter to obtain per-interface throughput, packet drops, errors, CPU, and memory usage; DMM issues PromQL queries such as $e$1 and averages over a rolling 1 minute. At the job level, MonIT supplies per-FTS-job bytes transferred, start/end times, retry count, failure flags, and average latency per file. DMM joins these metrics by rule_id and DTN IP and computes

$\mathrm{Valid}_e(v,p)=1$1

every 60 seconds. If efficiency is below $\mathrm{Valid}_e(v,p)=1$2 such as 0.5, or MonIT job throughput is below $\mathrm{Valid}_e(v,p)=1$3 such as 50 MB/s, the flow is flagged as underperforming, which can trigger LP re-solve, increased FTS concurrency, or an operator alert.

The reported evaluation is a closed testbed with approximately 10 simultaneous point-to-point rules carrying multi-TB datasets across WAN links of 100–400 Gbps between T2_US_UCSD, T2_US_Caltech, T1_US_FNAL, and T2_US_Nebraska. After LP solving and FTS tuning, each flow’s throughput sits within 90–95 % of its allocated share. Without DMM, Rucio + FTS alone typically gives a few big flows all the bandwidth and starves the rest; with DMM, multi-flow fairness is restored and high-priority transfers complete up to 30 % sooner in heavy-load scenarios. The stated limitations are the small scale of the current testbed, LP solve time that grows as $\mathrm{Valid}_e(v,p)=1$4 and becomes noticeable beyond 50 edges, and support only for point-to-point rules.

4. Distributed DMA as a DMM for on-chip point-to-multipoint transfer

Torrent recasts the DMM as a distributed DMA architecture for SoCs in which point-to-multipoint transfer is required but native multicast support is absent from standard interconnect protocols. Its key architectural decision is to embed lightweight Torrent endpoints at each AXI slave port and let them cooperate over ordinary point-to-point NoC links, leaving router pipelines, link protocols, and packet formats unchanged. The architecture is layered: the application layer places Torrents between DMA-like data-streaming engines and the AXI network interface; the transport layer packs and unpacks AXI bursts into a small virtual tunnel; and the network and link layers remain untouched 4-stage wormhole routers with 1-cycle per-hop links, for example in a 2D mesh with XY routing. A point-to-multipoint request is handled by one initiator Torrent attached to the source buffer and $\mathrm{Valid}_e(v,p)=1$5 follower Torrents attached to destination buffers, forming a logical doubly linked chain (Deng et al., 19 Dec 2025).

The fundamental mechanism is Chainwrite, a four-phase control flow. The initiator follows SEND_CFG → WAIT_GRANT → SEND_DATA → WAIT_FINISH → done. Each follower follows RECV_CFG → WAIT_GRANT → SEND_GRANT → WAIT_DATA → RECV_DATA → RECV_FINISH → SEND_FINISH → done. In Phase 1, the initiator dispatches small CFG packets in parallel, each carrying previous-hop and next-hop addresses for the doubly linked list. In Phase 2, Grant propagates backward from the tail; the initiator begins data only after receiving Grant. In Phase 3, data transfer moves forward, with intermediate Torrents forwarding each received frame immediately and also writing it to local memory. In Phase 4, Finish propagates backward from the tail to confirm completion. The CFG frame body is given as

$\mathrm{Valid}_e(v,p)=1$6

Because all data move along a single path, destination order materially affects latency and contention. Torrent therefore defines two schedulers. The greedy heuristic selects the nearest next destination whose XY route does not reuse previously used links when possible and has complexity $\mathrm{Valid}_e(v,p)=1$7, making it suitable for just-in-time decision. The global optimizer formulates the problem as an open-path Traveling Salesman Problem on the graph of destinations plus source with binary variables $\mathrm{Valid}_e(v,p)=1$8 and objective

$\mathrm{Valid}_e(v,p)=1$9

subject to exactly one outgoing edge per visited node, exactly one incoming edge per node other than source, subtour elimination constraints, and no return to source. It is solved off-line, for example via OR-Tools. The paper states that the TSP solver is exact and that the greedy heuristic is empirically within 1–2% of optimal in random layouts.

Performance is summarized through the point-to-multipoint efficiency

$v$0

with $v$1. Torrent Chainwrite reaches up to a 7.88× speedup over the unicast baseline for a 64 KB transfer to 8 destinations on FPGA using DeepSeek-V3 workloads. Setup and teardown overhead fit

$v$2

so that $v$3 gives approximately 1687 cycles. ASIC synthesis on TSMC 16 nm at 600 MHz reports approximately 1.2% SoC-level area overhead, approximately 2.3% SoC power overhead, and a per-destination cost of 207 $v$4. The comparative claim is that network-layer multicast increases router complexity and link width with $v$5, whereas Torrent keeps mesh routers unchanged and moves scaling cost to endpoint logic.

5. Hardware-transparent DMMs in disaggregated memory systems

DaeMon addresses a different data-movement problem: the performance penalty of accessing remote memory modules in fully disaggregated systems. Its DMM architecture is distributed into two lightweight hardware engines, one per compute component and one per memory component. The DaeMon Compute Engine sits on the FPGA or ASIC attached to each CPU chip and interfaces with a coherent link into the CPU cache hierarchy, a local-DRAM channel, and a packet link to the network controller. It intercepts DaeMon request packets generated by the normal page-fault handler or runtime on LLC or local-DRAM misses, enqueues them in internal queues, and manages network transfers, decompression, and metadata updates without OS or application changes. The DaeMon Memory Engine resides in the controller of each remote-DRAM component, accepts fetch requests, reads data from DRAM, optionally compresses them, sends packets back over the network, and tracks acknowledgments for dirty evictions (Giannoula et al., 2023).

To prevent bulk page migrations from starving latency-sensitive cache-line fetches, DaeMon partitions both the network link and the remote-DRAM bus into two logical bandwidth shares: cache-line transfers of 64 B and page transfers of 4 KB. With reserved fraction $v$6 for cache-line traffic, the long-interval byte ratio is approximately

$v$7

and the effective steady-state throughputs are

$v$8

The paper’s example sets $v$9, which for 4 KB pages and 64 B cache lines translates to roughly 21 cache-line fetches per page request. This mechanism is enforced by a Queue Controller that alternates page versus cache-line fetches according to the ratio and may issue idle cycles if a queue is empty.

Bulk page migration is further reduced by on-the-fly LZ77-based compression inspired by IBM’s MXT. Each 4 KB page is divided into four 1 KB blocks processed by four parallel engines, each with a 256 B sliding-window dictionary and peak throughput of 256 B in, 64 B out per cycle. Each 1 KB block incurs roughly 64 cycles of compression and 64 cycles of decompression. If the compression ratio is

$p$0

then transfer time becomes

$p$1

rather than $p$2 uncompressed. The reported motivation is that even with approximately 128 cycles of total compression and decompression overhead, empirical $p$3–$p$4 on typical data reduces bytes over the network by 2–3× and lowers queueing delay.

DaeMon’s movement policy is decoupled and multi-granular. It keeps separate paths and queues for sub-block traffic at cache-line granularity and page traffic at 4 KB granularity, along with InflightSub and InflightPage CAMs to avoid duplicate movement. Request handling decides whether to enqueue a page request, a sub-block request, or neither depending on existing in-flight state and buffer occupancy. Adaptive granularity selection then uses inflight occupancies $p$5 and $p$6 as runtime signals: if $p$7, favor cache lines; if $p$8, favor pages; if both are full, favor cache lines. The stated effect is to keep critical-path lines from stalling while still exploiting spatial locality when page movement is beneficial.

Evaluation uses a modified Sniper-x86 simulator with 3.6 GHz out-of-order cores, a conventional cache hierarchy, 17 GB/s local and remote DRAM, 100 ns or 400 ns network switch latency, and network bandwidth equal to DRAM-bus bandwidth divided by $p$9. Across 13 workloads, DaeMon improves system performance by 2.39× and data access costs by 3.06× over the widely adopted 4 KB page-granularity baseline. The detailed results also report that page-queue-only operation without compression reduces local-DRAM hit rate by approximately 8% on average, whereas DaeMon’s compression recovers almost all of that and ends less than 1% below full page-only. Robustness studies retain greater than 1.8× speedup under 1 $e$0s switch latency, network bandwidth at 1/16 of the DRAM bus, and four heterogeneous applications sharing the same compute node.

6. Cross-cutting principles, evaluation criteria, and recurrent limitations

Taken together, these DMM realizations indicate a small set of recurring design principles. First, all of them maintain an explicit representation of movement-relevant state: validity predicates in OMPDart, per-rule and per-edge state in the SENSE–Rucio DMM, chain configuration and endpoint role state in Torrent, and inflight/occupancy state in DaeMon. Second, all optimize selective transfer rather than indiscriminate copying: OMPDart moves only when a RAW dependence requires it and can restrict array ranges; the network DMM allocates bandwidth by merged priorities and lower bounds; Torrent sends one traversing copy of each flit across a logical chain; DaeMon distinguishes 64 B critical fetches from 4 KB bulk movement. Third, each relies on some form of feedback or reconfiguration: precise CFG placement of update directives, updateCircuitBandwidth and concurrency tuning, chain-order scheduling, and adaptive granularity selection.

The evaluation criteria also differ systematically by domain. OpenMP offload emphasizes total bytes transferred HtoD and DtoH, number of memcpy calls, wall-clock time in data transfer, and full application runtime. The WAN-transfer DMM emphasizes per-rule bandwidth assignment, fairness, host throughput, job throughput, and time to completion under heavy load. Torrent emphasizes point-to-multipoint efficiency, cycle-count overhead, area, and power. DaeMon emphasizes system performance, data access costs, local-DRAM hit-ratio recovery, and robustness under different latency and bandwidth regimes. This suggests that “efficient data movement” is not a single metric but a family of workload- and substrate-dependent objectives.

Several limitations recur. The SENSE–Rucio DMM currently supports only point-to-point rules, and its LP solve time becomes noticeable beyond 50 merged edges. Torrent’s optimal scheduler has higher CPU cost because it is formulated as a TSP and solved off-line. DaeMon depends on specialized engines and careful queue management, while OMPDart is tied to static analysis assumptions over OpenMP source. Another common misconception is that reducing bytes moved is sufficient by itself. The cited systems show a broader picture: correctness constraints can dominate when validity is ambiguous; fairness can dominate when large flows starve smaller ones; latency-sensitive small-granularity requests can require reserved bandwidth even when bulk throughput remains high; and topology-aware ordering can matter as much as raw bandwidth. In that sense, the DMM concept names a control problem—coordinating data movement under structural constraints—rather than a single architecture or algorithm.