arXiv CSopen access

Gutenberg: Taming Latency-Critical Cloud Services with Near-Data-Processing

· arxiv_cs

arXiv CS · Papers · License: Open Access

cloud distributed-computing parallel-computing

distributed computing, parallel computing, cloud

G UTENBERG: Taming Latency-Critical Cloud Services with Near-Data-Processing Qiushi Lin† and Phillip B. Gibbons‡ and Jovan Stojkovic† and Yiwei Zhao‡

arXiv:2609.06691v1 [cs.DC] 6 Sep 2026

University of Texas at Austin†, Carnegie Mellon University‡

the processing occurs at the DPU near/within the module holding the data. This design improves both performance and energy efficiency by leveraging the DPU’s low-latency, high-bandwidth, low-energy access to the module. Enabled by advances in fabrication such as 3D stacking [27], [46], the past decade has seen a growing body of NDP research (e.g., see the references of [59]) as well as the emergence of real-world industrial NDP products and prototypes [43], [74], [81], [86]. NDP systems have proven to be efficient on a variety of data-intensive workloads, including neural networks [21], [40], [56], [64], [71], graph analytics and GNNs [1], [3], [5], [19], [70], databases [31], [41], [47], [91]–[93], sparse linear algebra [2], [18], [35], [63], and genomics [15], [54], [73], [76]. However, most of these efforts optimize a single service on a dedicated CPU+NDP system. In contrast, NDP support as a multi-service resource remains comparatively underexplored, with only a limited number of existing works (e.g., [7], [39], [75], [77]). Unlike the single-service setting, a cloud node hosting multiple services at once must process a mix of requests from different services, while satisfying isolation [6], [13], [52] and fairness [17], [72] guarantees. Prior work falls short in addressing the following three key challenges of supporting multiple latency-critical cloud services on a CPU+NDP system.

Abstract—Latency-critical cloud services place growing pressure on memory while requiring isolation, fairness, and predictable QoS. Near-data processing (NDP) reduces data movement by executing requests close to memory, and prior systems further improve locality through caching and replication. However, writes make replica maintenance expensive, while uneven compute and memory traffic can overload a few NDP units and increase tail latency. Existing throughput-oriented schedulers do not fully address these challenges for co-located cloud services. We present G UTENBERG, a CPU+NDP system for mutable, latency-critical cloud services. G UTENBERG stages subpage updates in a CPU-resident delta buffer, allowing hot writable pages to remain replicated without eager full-page synchronization. It also adopts CPU helper cores to assist request execution when NDP execution or replica maintenance becomes costly. An online controller jointly decides page placement, replication, CPU/NDP execution, and routing using access patterns, queue pressure, and feedback from prior decisions. The system further enforces isolation and fair resource allocation across services. We also model-check CPU–NDP coordination protocol for correctness. We evaluate on TailBench using ZSim with Ramulatorcalibrated memory timing. Across evaluated services, G UTEN BERG outperforms prior systems, reducing average and p99 latency by up to 80.4% and 85.8%. It also improves isolation and fairness while adapting to changing workload behaviors.

I. I NTRODUCTION Many online cloud services are highly latency sensitive, including in-memory key-value stores and caches [8], [11], [16], [55], [61], [88], transaction processing over relational and financial-graph data [26], [38], [50], [65], [67], [80], search and ranking [4], [23], [25], [36], [57], and machine-learning inference services spanning translation, speech, and image and media processing [9], [22], [28], [36], [58], [87]. Such latencycritical services store data in memory (accessing SSDs would be too slow) and are subject to strict service level objectives (SLOs) on the tail latency of request processing. Achieving low latency while also maximizing request throughput places significant pressure on the memory system of the cloud node hosting the service. Often, request latency and throughput are bottlenecked by the latency and limited bandwidth of memory access, known as the memory wall problem. Near-data-processing (NDP), or processing-in-memory (PIM), has recently reemerged as a promising architectural solution to the memory wall problem. By integrating compute units (data processing units (DPUs)) near or within memory modules, NDP enables computation to be performed close to where data reside. Instead of incurring the high cost of fetching the needed data from the module back to the CPU for processing (as in traditional von Neumann architectures),

Challenge I: No or Suboptimal Support for Workloads with Mutation. CPU+NDP systems are most effective when the data needed for a request are co-located on the same memory module; otherwise costly data movement between modules is required. Existing CPU+NDP systems use data caching/replication to enable such co-location, typically at page granularity. However, many CPU+NDP systems (even single-service ones) employ techniques targeting read-only settings: E.g., ABNDP [78] caches read-only data, PIMCloud [7] replicates read-only pages, NDPExt [49] replicates read-only streams, RecNMP [37] caches read-only embedding tables, and RecSSD [84] accelerates inference-time embedding lookups. These read-only designs are problematic for two reasons: (i) Cloud services include stateful and mutable components [16], [38], [55], [65], [80], [88] where techniques designed for read-only settings become less effective, especially for update-heavy services; and (ii) Even in read-dominated services, a small amount of mutable data in a page prevents caching/replication of any hot read-only data in the page, resulting in costly data movement even for that read-only data. Moreover, any solution efficiently supporting mutations must

be managed in the context of multiple simultaneous services.

whether related requests execute on the CPU or a DPU— but do not by themselves decide which action to take. To address Challenge II, G UTENBERG uses observed memoryaccess patterns rather than data mapping skew alone, because balancing pages/bytes reveals little about request queueing (§II-B). G UTENBERG assigns each candidate page action a unified utility that rewards recovered locality and queue relief while considering installation, update, and capacity costs (§III-C). This formulation captures compute imbalance and data movement in a common objective rather than treating data movement as a secondary consequence of compute balancing. Decisions operate at two timescales: policy windows determine a page’s permitted execution paths and amortize data movement, while each request selects among those paths based on current queue pressure (§III-C). Finally, a negativefeedback loop updates cost and decision terms using system measurements. Minimum residence intervals and bounded perwindow action budgets prevent oscillation (§III-C4). Challenge III issues (memory isolation and fair QoS) are considered in all the mechanisms and policies above, rather than forming a separate layer on top of them. The CPU acts as the single trusted control point. It maps each (service identity, virtual page) pair to the physical address domain that the service may access, and this identity accompanies requests, delta-buffer entries, replicas, and page transitions, so an otherwise profitable action that crosses a protected domain is rejected (§III-D). Each service also holds admission credits and a page-change budget for the shared CPU and NDP capacity, within which accumulated SLO debt prioritizes competing work, so that a bursty service cannot monopolize the shared queues or the reconfiguration budget. To improve throughput, we do allow a service to greedily use CPU and DPU capacity that is otherwise left idle by co-running services. We evaluate G UTENBERG on mutable online-service workloads from TailBench [36] in ZSim [69], with memory timing calibrated against Ramulator [42]. Our results show that G UTENBERG (i) matches or outperforms the baselines across the suite, reducing average and p99 latency by up to 80.4% and 85.8%, respectively; (ii) provides strong isolation and fairness; and (iii) continuously adapts to dynamic workloads with diverse characteristics. In summary, the contributions of this paper are:

Challenge II: Incomplete Joint Balancing of Computation and Data Movement. Prior work effectively balances computation across DPUs, but typically treats such load balance as the primary scheduling objective. Skewed memory traffic and data-movement pressure are only secondary optimization concerns or byproducts of the designs. However, balancing the working set of pages among the DPUs and balancing the DPU compute does not imply data access balance: such balanced mappings can still result in sharply different access loads (and hence queuing delays) for skewed access patterns (§II-B). Recent system designs [30]–[34], [93] on real UPMEM-PIM hardware [81] show that both forms of imbalance substantially affect performance, motivating a “push-pull” execution that jointly optimizes both computation and data movement. Jointly optimizing computation and data movement to avoid imbalance (and the resulting queuing delays) is particularly important in the multi-service setting. Challenge III: Isolation and Fairness. We study a setting in which the cloud node provides a set of predetermined services, which are orchestrated as a collection by the node. The goal is to minimize tail latency for each service, as well as performance isolation and fairness, across a range of queries-per-second (QPS) arrival rates. Achieving this often requires balancing computation for high resource utilization while preserving data locality to reduce data movement [7], [29], [78]. However, these objectives inherently conflict. Our Solution: G UTENBERG. To address these three challenges, we present G UTENBERG, a cooperative CPU+NDP system that reduces the tail latency of latency-critical cloud services whose hot data are potentially mutable. To address Challenge I, we do not restrict replication to read-only pages, but extend it to mutable and even write-intensive pages through fine-grained management that keeps replica maintenance lightweight. Instead of synchronizing an entire page after every update, a writer stages the modified bytes in a CPUcontrolled delta buffer, while the controller publishes only a versioned dirty-region notification to the page replicas. Each replica continues serving clean regions locally and fetches pending bytes only when a read accesses a region marked dirty (§III-B1). Full-page synchronization is not eliminated, but removed from the common write path: staged updates accumulate and are consolidated in bulk once their footprint (number of bytes) or update chain exceeds a threshold. For pages with sufficiently dense writes, however, even delta staging cannot make replication cost-effective. For such pages, G UTENBERG routes requests to CPU helper cores that preserve locality through a dedicated compute-cache partition (§III-B2). As both execution paths share the same logical page state, we formally verify the coordination state machine for single-authority and single-writer safety, legal replica serving, bounded state, and request progress across all interleavings in the checked finite configurations (§III-B3 and §IV-F). These mechanisms expand the page-management action space—where pages reside, whether they are replicated, and

We support replication of mutable pages using a CPUresident subpage delta buffer, and route write-dense pages to CPU helper cores to assist execution (§III-B1, §III-B2). • We model-check the CPU–NDP coordination protocol for safety and bounded progress (§III-B3, §IV-F). • We coordinate page actions using a unified utility over locality, queueing, and data-movement costs at both policy and request timescales, with negative feedback (§III-C). • We provide isolation and fair QoS using the CPU as the trusted control point for address domains and per-service resource budgets (§III-D). • Evaluation of G UTENBERG using ZSim [69] on TailBench [36] shows lower average and p99 latency than •

Cloud Services www

www

Orchestration Core Pool

Component

Helper Core Pool

Configuration

Host CPU CPU cache

Admit

www

TABLE I: Ramulator-calibrated default configuration.

Host CPU

Queue

2.4GHz Haswell; 40 cores in total (orchestration and helper cores) 32 KB L1I, 64 KB L1D, 512 KB private L2 per core; 2 MB shared last-level cache (LLC) capacity per modeled host core; one 512 KiB LLC partition reserved for the delta buffer NDP organization 16 stacks; 8 Silvermont workers/stack (128 total) at 2.0 GHz Memory controllers 8/stack; 32-entry request queue Inter-stack link 160 GB/s; 4 host ports; 64-entry link queue Memory model HMC timing calibrated against Ramulator [42] Granularity 4 KB pages; 64 B cache lines

Route

Feedback Control

Reserved Δ-Buffer

Compute Cache

Shared CPU LLC

runtime assigns each service a protected address domain and uses pages as the unit of data placement and replication. Each page belongs to one service domain and has one designated home stack that stores a complete copy of the page; requests may execute on NDP workers or CPU helper cores. In the absence of replication, NDP accesses to a page are served through the DDR-controller queue on its home stack.

Memory Controller / Interconnect

Request path Feedback control

NDP Stack 0

NDP Stack 15

Request Queue

NDP Cores

Local Memory

B. Motivation: Joint Page Management and Execution Fig. 1: Target platform and G UTENBERG’s CPU–NDP request flow. CPU orchestration cores admit, queue, and route requests to CPU helper cores or NDP workers. Helper cores use the compute portion of the CPU last-level cache (LLC), while other reserved LLC ways form the CPU delta buffer.

Stack-local NDP execution is efficient only when accessing data in its local memory; otherwise fetching the data incurs costly data movement and memory-controller contention. In the absence of replication, each access is served through the DDR-controller queues of its page’s home stack, regardless of the issuing NDP worker. We quantify this effect with ZSim runs of a no-replication key–value service that executes the YCSB [10] over Masstree [55] in TailBench [36]. Its synthetic generator issues a 50/50 GET/PUT mix and groups 256 YCSB operations into each service query. We compare its default uniform-key access with Zipf access [95] (α = 0.80) at offered loads of 20–120K queries per second (QPS). Each setting uses the default 16-stack, Ramulator-calibrated configuration in Table I and measures 10,000 completed requests. At 80K requests/s with Zipfian key popularity (α = 0.80), Fig. 2(a) reports maximum-to-minimum ratios of 1.12× for distinct-page footprint and 3.32× for DDR-access volume across stacks. Balancing workers and page footprints therefore does not balance controller demand. Fig. 2(b) tabulates mean DDR-controller queue wait per access at the same offered loads. Relative to the default uniform-key generator, Zipfian access adds 11–18% queue wait through 80 K QPS. At 120 K QPS, the penalty reaches 27%, increasing mean wait from 56.8 to 72.1 ms. Skew therefore amplifies controller queueing, particularly near saturation. The same 80 K-QPS, α = 0.80 run shows whether hot pages are accessed from multiple stacks. We rank pages by DDR-access count and select the smallest set that accounts for 80% of all DDR accesses (the hot set). For each page in this set, we count how many of the 16 stacks issue requests to it. Fig. 2(c) groups hot-set accesses by this requester-stack count. It shows that 64.0% of hot-set accesses target pages requested from multiple stacks; 58.2% target pages requested from all 16 stacks. Replicating these pages at requester stacks creates additional stack-local service points and distributes their accesses across DDR-controller queues.

prior CPU+NDP systems, together with isolation, fairness, and workload adaptivity (§IV). II. BACKGROUND AND M OTIVATIONS A. Target CPU+NDP Platform and Service Model Following prior node-level QoS managers [6], [7], we consider a single NDP-enabled server shared by multiple cloud services. This scope isolates the challenges arising from resource contention, data placement and update maintenance within an NDP-enabled node. Broader scopes, such as coordination across multiple NDP-enabled servers, are also important, but are often compatible with and orthogonal to our design, and are thus left to future work. We target a CPU+NDP system where a host multi-core CPU connects through memory controllers and an interconnect to multiple NDP stacks, as shown in Fig. 1 (which also highlights G UTENBERG’s features–see §III). Each stack is comprised of a DPU with one or more NDP cores (4 in the figure) and a local memory. Lightweight NDP workers access the local memory via requests served through the corresponding DDRcontroller queue (Request Queue). On-stack accesses use the local data path, while accesses to remote stacks traverse the shared inter-stack path over the interconnect. Unless stated otherwise, our experiments use the default 16-stack setup in Table I, following the common system scope shared by prior work [7], [78]. We focus on co-located, latency-critical services whose requests read and update in-memory data structures, such as database records, indexes, and key–value objects. A CPU-side

Working set DDR accesses

1.5

Rate Uniform keys (K/s)

1.0 1.12× pages 3.32× accesses

0.5 1

α = . 80 Penalty

21.5 μs

25.4 μs

+18%

49.6 μs

58.8 μs

+18%

53.4 μs

59.4 μs

+11%

120

56.8 ms 72.1 ms

+27%

Stacks (sorted by accesses)

60 40

36.0

20 4.7

2-8

1.1

9-15

Requester stacks / hot page

Hot-set accesses (%)

2.0

Hot-set accesses (%)

Load / stack mean

(a) Footprint vs. DDR demand (b) Skew penalty in queue wait

(d) Write intensity 40

36.9 30.9

30 20

15.5

16.8

0--10 10--40

10 0

>40

Page write fraction (%)

Fig. 2: Page-level demand, controller queueing, and write behavior in Masstree/YCSB without replication on the 16-stack platform in Table I. Each setting covers 10,000 measured requests; (a), (c), and (d) use 80 K QPS with Zipfian key popularity (α = 0.80). (a) Distinct-page footprint and DDR-access volume per stack, normalized to their respective stack means. (b) Mean DDR-controller queue wait per access under the default uniform-key generator and Zipfian access (α = 0.80) at matched QPS. (c) Fraction of hot-set accesses grouped by the number of stacks requesting each page. (d) Fraction of hot-set accesses grouped by each page’s observed write fraction. The hot set in (c) and (d) is the smallest set of pages covering 80% of DDR accesses.

(i) Compared with CPU platforms, NDP lacks a large, coherently shared, and maturely managed memory space. Though CPU resource managers account for cache capacity, caches are relatively small and sit above a unified memory system accessible by all cores. In contrast, each DPU is tightly coupled to a limited local memory partition, while runtime control mechanisms such as preemption, migration, and finegrained resource reallocation are substantially more restricted. (ii) NDP also differs from CXL-based systems and distributed clusters in that placement is simultaneously a compute- and data-routing problem. Existing designs on these two platforms typically keep one side fixed. CXL systems keep computation at the host and fetch data, whereas distributed systems often keep data at a server and route requests/tasks to it. In NDP, the system must jointly decide where computation executes and where data reside, while coordinating a powerful host CPU with many lightweight NDP workers that offer limited support for fine-grained runtime control and workload migration.

However, requester spread alone does not make replication inexpensive because most hot pages also receive writes. Fig. 2(d) uses the same hot set and groups pages by write fraction (writes divided by all accesses to that page); each group’s height is its share of hot-set accesses. Only 15.5% of hot-set accesses target read-only pages, whereas 36.9% target pages whose write fraction exceeds 40%. On writeheavy pages, NDP-side read caches are repeatedly invalidated, while eager replication turns fine-grained writes into pagescale synchronization. Requests modify sub-page data, but cache invalidation and replica synchronization operate on entire pages. Our design addresses this granularity gap by tracking and transferring only modified sub-page regions. Replication creates a tradeoff within NDP: additional replicas increase stack-local service capacity (the number of stacks that can perform a cheap local access to the page), but every writable copy adds update traffic and synchronization work. This cost is especially important for lightweight NDP cores, whose area-constrained caches offer limited capacity for frequent writes with poor locality. The host CPU provides a larger cache and stronger compute resources. G UTENBERG extends the CPU beyond orchestration by using these resources to buffer fine-grained updates and execute selected requests. Within each service, G UTENBERG dynamically decides where each page resides, whether it is replicated, and whether its requests execute on the CPU or an NDP stack, using observed page accesses and DDR-controller pressure. §III details these mechanisms and policies.

III. G UTENBERG D ESIGN A. Design Overview Fig. 1 summarizes how G UTENBERG controls and executes service requests across the CPU and NDP stacks. A request first enters the CPU orchestration pool, whose cores perform admission control, queueing, and routing. For each request, the router selects a CPU helper core or an NDP worker as the execution location. CPU helpers use part of the LLC allocated to request execution. Other separate reserved LLC ways form the CPU delta buffer, which is used to temporarily hold subpage updates. CPU helpers and NDP workers can both execute requests from the same service. §III-B presents two design components—the CPU delta buffer and CPU helper execution. The delta buffer organizes replica updates in the system at sub-page granularity instead of synchronizing the full page after each write. CPU helper cores enable the CPU to execute selected requests. An orchestration layer coordinates CPU and NDP execution at two timescales. Over long policy windows, it selects pagelevel actions, including where each page resides, whether it is replicated, and whether CPU execution is enabled. At request

C. Related Work: Cloud Services on Other Platforms Resource management for cloud services has been studied on platforms beyond NDP, including heterogeneous and shared CPU systems [6], [12], [13], [62], general-purpose distributed clusters [17], [24], [51], [82], CXL and disaggregatedmemory systems [20], [48], [68], [94], QoS-aware service platforms [66], [83], [90], and shared accelerator clusters [53], [60]. However, NDP fundamentally differs from these platforms in how computation and data interact, preventing prior designs from being directly applied without substantial adaptation.

Each region is further divided into thirty-two fixed 8B slots. When a region is modified, the CPU delta buffer creates or updates a corresponding delta entry stored in the CPU LLC. The system allocates these entries only for pages that currently have writable NDP copies. Each entry contains a 16-bit page index which serves as an identifier in the delta protocol, a 4bit region index, a 32-bit version number, and a 32-bit bitmap. Bit i is set when the entry contains an updated value for bytes [8i, 8i + 7]. In addition to the header, the entry stores one 8B updated value for each set bit. As an example, writes to bytes 40–47 and 56–63 of a region set bitmap bits 5 and 7 and store two 8B values. A later write to bytes 40–47 replaces the value associated with bit 5 in the same entry rather than appending a new write record. Thus, each region with buffered updates uses one bounded-sized entry that stores only the latest value for each modified 8B slot. The page index, region number, version, and bitmap fit within a 16B header, while the update values occupy 8–256B. The home NDP stack retains the complete 4KB base page. To create a new replica, the system copies this page and then applies any updates in the CPU delta buffer. Each NDP replica maintains a 16-bit Dirty Map for each page, with one bit per region, and records the 32-bit version last applied to each region. A clean bit (0) means that its local 256B region includes the latest update already published by the CPU delta controller. A dirty bit (1) means that the copy must obtain the buffered updates before serving a read. b) Publishing a Write: We first start with a simpler case. Fig. 4(a) shows the procedure of a write handled by NDP, without CPU helpers. The CPU-assisted case is described later. Let p denote the page being written and r one of the updated 256B regions. The writer is the NDP worker executing the request, which may reside on either the home NDP stack or a replica stack. The writer sends the modified 8B values (patch(p, r)) to the CPU delta controller. The controller merges them into the corresponding delta entries in the CPU LLC and assigns a new 32-bit version to each modified region. After recording all updates from one request, the controller summarizes the modified regions of each page into a 16-bit bitmap M . For each modified page, it then sends every active NDP replica one 4B D IRTY message, consisting of a 16-bit page index ip and the 16-bit region bitmap M . This message aggregates all unpublished modifications to the page up to and including this request. If a request modifies multiple pages, the controller sends one message for each page. The versions and updated values remain in the CPU LLC and are returned only when an NDP replica fetches the latest data (Pull(p, r, v)). After receiving the message, each active replica sets the region bits indicated by M in the page’s Dirty Map and sends an acknowledgment. The write completes after all active replicas acknowledge. Thus, the modified values are stored only once in the CPU delta buffer, with no memory writes at the NDP replicas. Repeated writes to the same 8B slots overwrite their buffered values, and a replica fetches only the final values when it later reads the (dirty) region.

(a) Page-granular writable replication NDP 0

NDP R (replica) 4-KB sync 2

replicas 1

64-B write

(b) Fine-grained updates + CPU assistance Sparse writes: retain replica

Dense writes: CPU assist Helper cores

CPU Δ-buffer

pull

Compute cache

minor Δ

CPU assist

replica

read request

home response

request

page sync

pull

minor Δ

Fig. 3: Supports for writable pages. (a) Eager replica maintenance turns a 64B write into a 4KB transfer to every replica. (b) G UTENBERG stores modified sub-page data in CPU delta buffer and can execute selected requests on CPU helper cores.

time, a router uses short-window system states to select a CPU or NDP worker for request execution. Observed latency and queueing behavior inform the next long-window decision. §III-C details these algorithms, while §III-D applies serviceisolation and resource-allocation constraints to both decisions. B. Enabling CPU–NDP Cooperation Page-granular replication can make small writes expensive. As in Fig. 3(a), updating a small object may trigger a copy of the entire 4KB page if eager writable replication is used, such as in HyPer [38]. Recent NDP work [7] avoids this write amplification by restricting replication to read-only pages, which however prevents write-intensive services from benefiting. G UTENBERG adds the two design components in Fig. 3(b) to enable efficient writes/updates. A CPU delta buffer stores only the modified sub-page data, which a replica fetches when a request reads the affected region. CPU helper cores provide additional executors for hot requests. This subsection explains how the two components work. An orchestrator (§III-C) uses these components and decides when to replicate/migrate pages and whether to execute a request on the CPU or an NDP stack. 1) Fine-Grained Writable Replication: a) Delta-based Representation: G UTENBERG retains 4KB pages as the unit of addresses, placement, and replication. Using the same granularity for replica updates, however, would trigger write amplification at every small write. We therefore divide each page into sixteen 256B regions. A region is the unit at which an NDP replica records whether its local data includes the latest updates and, when it does not, requests those updates from the CPU. Within each region, the delta buffer stores and transfers only the modified values.

Policy window

(a) Writable-replica path NDP writer

NDP replicas

CPU ∆ ctrl.

patch (p, r)

stage; assign v D IRTY(ip , M ), 4 B

Profile

ACK (all)

Page action Move

Replicate

CPU assist

Page state enabled

Per request

complete dirty read P ULL(p, r, v) patch v ; apply/return

Request

(b) Switching a page to CPU execution Orchestrator

feedback

stop admission

NDP paths

Router

CPU

Outcome

Fig. 5: Two-timescale orchestration: page actions enable execution paths, and per-request routing selects a worker.

CPU helper

drained

orchestrator (§III-C) decides when to move pages into or out of CPU helpers. The use of such helpers on a host CPU that is significantly more powerful than any other compute resource (PIM stack) is an option on CPU+NDP systems not available/considered by distributed-cluster systems. a) Switching to CPU execution: Fig. 4(b) shows how a page transits from NDP to CPU. The controller first stops routing new requests to the page and drains its previously routed requests. It then applies the page’s pending delta entries and waits for the full-sync barrier. After synchronization completes, the controller disables the page’s NDP execution and routes future requests to CPU helpers. These helper cores execute requests using the compute portion of the CPU LLC. b) Returning to NDP execution: When a hot page cools down or the CPU LLC faces high capacity pressure, the controller stops routing new requests for the page to CPU helpers and waits for all outstanding requests to complete. It then writes the CPU’s latest page contents to the selected home stack and replicas. After these copies acknowledge the update, the controller re-enables the NDP paths and resumes routing. 3) Formally Verified Coordination Model: G UTENBERG uses two protocols that must be carefully ordered—publishing updates to writable replicas and switching a page between NDP and CPU. We model both protocols as a TLA+ state machine [44], [45]. The model allows request service, write publication, replica Pulls, delta reclamation, and CPU–NDP switching to interleave in any valid order. The checked invariants require that (i) CPU and NDP paths are never writable simultaneously during a switch, (ii) pagestate transitions begin only after all previously routed requests have completed, and (iii) a replica that has missed an update cannot complete a read. Delta entries are reclaimed and page execution is switched, only after all outstanding requests complete and the required replicas pass a full-sync barrier. Together, these invariants prevent stale reads and lost updates in the coordination protocol. The temporal checks further verify that queued requests eventually complete and that every initiated transition finishes under weak fairness. §IV-F reports our results using the TLC model checker [89].

consolidate + barrier enable CPU path route page requests

Fig. 4: Ordered operations for (a) publishing and fetching updates and (b) switching a page from NDP to CPU execution. c) Reading an Updated Region: A clean region is read directly from the replica’s local memory. If a read finds the region dirty, the replica marks a Pull as in progress, clears the dirty bit, and sends a P ULL message containing the page index, region index, and the replica’s current version. Subsequent reads to the same region at that NDP replica wait in its local request queue until the Pull finishes; reads at other replicas proceed independently. The home stack is not involved in this process. The CPU returns the delta entry’s version, 32-bit bitmap, and updated 8B values. The replica applies these values to its local 256B region and records the returned version; the Pull completes after both steps. Any D IRTY received before completion of the Pull sets the dirty bit again. The replica serves pending reads only if the bit is clear; otherwise, it repeats the Pull. d) Delta Entry Reclamation: All delta entries share a fixed 512KB LLC partition. The controller reclaims entries when this partition cannot hold a new entry, or before moving a page, removing one of its replicas, or switching the page between NDP and CPU execution. It first stops routing new requests to the page and waits for all previously routed requests to complete, a step called draining the page. The controller then applies each delta entry to its home and to each replica that will remain active. A full-sync barrier completes once these copies acknowledge the installed versions. The controller can then discard the entries and resume routing, because no new writes were admitted during synchronization. 2) CPU Helper Execution: For some pages, NDP execution suffers high latency due to controller queueing, remote accesses, and frequent replica updates. These pages are often heavily read and written, making them good candidates for CPU helper execution. The orchestrator can therefore temporarily route requests for such a page to CPU helpers. This decision is made per page, so other pages from the same service may continue running on NDP workers. An

C. Memory-Pattern-Driven Orchestration §III-B describes the basic actions available to improve system efficiency. This subsection presents an orchestrator that decides when to take each action and to which page/request.

Fig. 5 provides a high-level overview of the orchestrator, which separates page management from request dispatch. Page management (upper) periodically (at “policy window” timescales) migrates/replicates pages, or enables CPU assistance for selected pages. Request dispatch (lower) routes each request only to the workers currently enabled by the page. Observed results inform the decisions in the next policy window. We only sketch the functions and parameters that control the orchestrator. Further details (e.g., specific thresholds) will be released in future versions. 1) Page States and Signals: G UTENBERG maintains four page states—NDP-home, read-replica, delta-replica and CPUassisted. Migration and cooldown (§III-B2) are temporary transition states rather than additional execution paths. For each page, the orchestrator may choose to migrate its home stack, add/remove read replicas, add/remove update-aware delta replicas, or enable/disable CPU helpers. The active replica set may span multiple NDP stacks, providing several locations for local reads. Writes from any execution location commit through the CPU delta controller (§III-B). At each policy window, the controller collects per-page read and write activity, requester-stack distribution, remote accesses, patch density, page residency, and the worker and DDR-controller queue lengths observed under the previous system state. It first removes actions that would not address the current bottleneck or would violate page-state, residency, service, or capacity constraints. For a hot page requested from several stacks, the controller may add read replicas when the page is not being written. When writes modify only a small number of 8B units, it may keep writable replicas active using the delta buffer. When the predicted costs of NDP queueing, remote accesses, and replica updates exceed the cost of CPU execution, it may assign the page to CPU helper cores. 2) Latency-Oriented Page Actions: For each eligible action a on page p, we predict its amortized per-request latency gain: b θ (p, cp ) − L b θ (p, cp⊕a) − Gt (p, a) = L t t

Algorithm 1: Policy-window page orchestration Input: profiles Pt , installed system state Ct , entitlements E, resource capacities K, coefficients θt 1 Update θt from predicted and observed outcomes of completed actions 2 A ← ∅ 3 foreach managed page p do 4 foreach legal action a for p do 5 if a passes memory, state, entitlement filters then 6 compute Gt (p, a) using Equation (1) 7 if Gt (p, a) exceeds the hysteresis margin then 8 add (p, a, Gt ) to A 9 sort A by decreasing predicted marginal gain 10 foreach (p, a, Gt ) in A do 11 if a fits projected stack load, E, K, and the window budget then 12 install a through the full-sync barrier 13 update projected queues and remaining capacities 14 remove remaining candidates for p from A

Algorithm 2: Per-request worker selection Input: request r, service ID s, installed page state cp , queue snapshot Q, entitlement credits Es 1 translate (s, VA) to protected page p 2 W ← workers on the CPU/NDP paths enabled by cp 3 remove workers that fail page-state, address-domain, or entitlement checks 4 if W ̸= ∅ then 5 compute Equation (2) for each w ∈ W 6 w⋆ ← arg minw∈W Tb(r, w) 7 charge the selected resource credit and dispatch to w⋆ 8 else 9 retain r in the service admission queue

candidate. This makes decisions across pages interdependent without claiming an impractical global optimum. 3) Per-Request Worker Selection: Page actions create capacity; the request router consumes it. For an arriving request r to page p, the current page state first determines the legal home, replica, and CPU-helper paths. The router expands those paths into concrete workers and predicts the completion time at worker w: Tb(r, w) = Qworker (w) + QDDR (dw ) + Texec (r, w) (2) + Tmemory (p, dw ) + Tvisibility (p, dw ).

btransition (p, a) C . (1) bresident (p, a) N

bresident is the Here cp ⊕ a is the post-action system state, N expected accesses during its minimum residence interval, and θt contains the online-calibrated coefficients. All terms are btransition expressed as time per request. The transition term C includes page movement, delta synchronization, and the CPU– NDP switching steps described above. The latency estimate accounts for worker and DDR-controller waiting, CPU/NDP execution, local or remote memory service, replica visibility work, and the write-maintenance traffic implied by the observed memory pattern. This single latency objective avoids separately rewarding locality and queue relief when both arise from the same redirected accesses. Alg. 1 ranks positive-gain candidates and admits them greedily under target-stack load, replica capacity, CPU-helper capacity, per-service entitlements, and a bounded number of mutations per window. It admits at most one action per page and updates projected load before considering the next

Qworker and QDDR are distinct: the former captures pending execution at the worker, while the latter captures contention at the worker’s memory stack. The remaining terms distinguish CPU from NDP execution, local from remote memory, and clean from dirty-replica access. The fast path in Alg. 2 never creates a replica or changes ownership. It reacts to short queue bursts by choosing among already legal workers, while the policy window amortizes data movement and changes which workers can be considered. 4) Outcome-Driven Autotuning: The cost coefficients are not fixed offline. Before installing an action, G UTENBERG records its predicted queue relief, latency gain, remote traffic, and patch/update cost. After the action’s residence interval,

TABLE II: Evaluated online-service workloads.

it compares those predictions with the observed outcome and updates the corresponding coefficient. A representative multiplicative update is # " Ok,t , (3) θk,t+1 = θk,t (1 − η) + η bk,t , ϵ) max(O bk,t are an observed and predicted cost comwhere Ok,t and O ponent. Thus, unexpectedly high synchronization cost makes further delta replication less attractive, whereas greater-thanpredicted queue relief raises the value of an additional local service point. Updates are maintained per action class, with ratios and coefficients bounded to prevent a single noisy window from dominating later decisions. Minimum residence intervals, cooldown, hysteresis, and per-window action bounds damp oscillation. This prediction–action–observation–correction loop is the runtime autotuner; it is not an offline system state search.

Workload

Request

Description

Silo [80] Masstree [55]

TPC-C OLTP [79] YCSB key-value [10]

Xapian [85] Other TailBench services [36]

Search query Service req.

Mutable records, validation, hot sets Irregular index traversal; configurable read/write ratio Posting/index traversal Translation, speech, image, and OLTP mixes

TABLE III: System designs used in the evaluation. System

Routing, placement, mutable-data and CPU division policy

PIMCloud [7]

Persistent five-window QoS signal; private-page migration; cautious replication of hot read-only pages; writable pages remain unreplicated; CPU/NDP execution selected by its algorithm Traveller DRAM cache at address-derived camp locations; camp-aware locality/load routing; write-triggered invalidation; no CPU–NDP cooperative execution in its design Queue-aware routing; feedback-guided hot/dirty page actions; delta-buffered writable replicas; 40 CPU cores for orchestration + 0 CPU helper cores Same routing, page policy, and delta buffer as G UTENBERG-NDP; 20 CPU cores for orchestration + 20 CPU helper cores

ABNDP [78]

G UTENBERG-NDP

G UTENBERG

D. Isolation and Fair QoS a) Security Isolation: The CPU maps each (service identity, virtual page) pair to a protected physical address space assigned to that service. Each service registers the virtual-page ranges containing its mutable state, and each request carries the service identity through admission and routing. Delta entries, replicas, and transition metadata carry the same identity tag, allowing the controller to reject any cross-service access or update. Co-running services share hardware resources but never mutable physical pages. Cross-service page sharing is currently outside the scope of G UTENBERG. b) Performance Isolation and Fairness: We use a hierarchical elastic scheduling that first protects each service’s guaranteed share and then distributes that share among its users. Each service receives resource entitlements for NDP workers, CPU-helper time, replica capacity, delta-buffer capacity, and the rate of page actions. These entitlements limit the candidate workers considered by Alg. 2 and the page actions considered by Alg. 1. Among the choices allowed by these limits, the scheduler prioritizes services according to their accumulated normalized SLO debt. After each scheduling window, service s updates its SLO debt as Ds ← max{0, Ds + (qs − q̂s )/qs }, where qs is its target SLO-satisfaction ratio and q̂s is the ratio observed in that window. We evaluate fairness using both per-service and worst-service SLO satisfaction, rather than aggregate throughput alone. The scheduler remains work conserving—a service may borrow underutilized resources, but must return them when the entitled service becomes active. Data-domain checks prevent unauthorized memory operations, while resource entitlements prevent a noisy service from monopolizing queues, helpers, replica space or reconfiguration bandwidth, ensuring fairness.

link usage, allowing end-to-end latency to include queueing caused by data placement. We compare all methods using the same hardware configuration, request arrivals, random seeds, and measurement boundaries. Table I summarizes the default hardware configuration used unless stated otherwise. Table II summarizes the evaluated workloads. Silo and Masstree are two primary workloads used to study routing, page placement, writable replication, and CPU assistance. The remaining TailBench services broaden the evaluation across search, translation, speech, image inference, and OLTP workloads with different datasets and execution footprints. All latency results use the complete measured instruction and memory-access streams from ZSim traces. Table III compares all methods using the same CPU+NDP resources. ABNDP and G UTENBERG-NDP use all 40 host cores for orchestration, including request routing, feedback profiling, and page actions, without executing service requests on these cores. PIMCloud’s scheduling algorithm assigns selected requests to CPU cores. G UTENBERG assigns 20 cores for orchestration tasks and the other 20 to help execution. The PIMCloud baseline [7] follows its original page-eligibility rules and decision cadence. It waits for five consecutive 100ms QoS windows, migrates private pages, cautiously replicates hot shared read-only pages, and leaves writable pages unreplicated. ABNDP [78] reserves part of each NDP unit’s local DRAM as a Traveller Cache, maps blocks to a small set of camp locations, and considers both locality and load when routing work. Writes will invalidate cached copies. A. Homogeneous-Service Performance

IV. E VALUATION

We first evaluate whether G UTENBERG reduces service latency as request intensity and access skew increase. Here, α denotes the Zipf exponent [95] that controls key-popularity skew. α = 0.80 and α = 0.99 represent moderate skew and a highly concentrated hot set, respectively.

Experimental Setup. We evaluate online cloud services using ZSim [69], with its DDR controllers calibrated against Ramulator [42]. ZSim tracks each request’s identity, arrival time, CPU/NDP route, destination stack, and controller and

PIMCloud

Gutenberg-NDP

Silo | Original

200

Avg. latency (μs)

ABNDP

TABLE IV: Component-removed/Full ratios (−C: G UTENBERG-NDP/Full mean); above one favors Full.

Gutenberg

Masstree | Original

Silo

Mtree

1.34 1.24 1.41 2.24 1.16 ms

1.37 1.13 1.13 1.37 0.58 ms

600 150

−Q −P −∆ −C Full p99

500

100

400

300 200 10

Avg. latency (μs)

α = . 80

200

2000

150

1500

100

1000

500 5

α = . 99

100

200 20

2000

1.0 0.8

0.69

10% 296.2

20% 291.2

Write fraction / Full p99 (ms)

TABLE V: End-to-end p99 normalized to PIMCloud.

20 10

1.13 1.06

Fig. 8: Delta buffering under writes. No-∆/Full p99 across write rates; above one favors Full.

α = . 99

1000 5

1.14

3000

300

Delta buffering under writes

120

400

100

1.2

2% 5% 457.9278.1

4000

High latency (ms)

Avg. latency (μs)

120

No-Δ / Full p99

Input rate (Kreq/s)

100

120

Input rate (Kreq/s)

End-to-end p99 latency (normalized to PIMCloud)

Fig. 6: Single-service latency across load and skew. End-to-end average latency versus QPS for Silo and Masstree under their original and Zipf-skewed request streams. Original denotes each workload’s default, near-uniform request distribution. Each data point averages 10K measured requests.

Fig. 6 shows two consistent trends. First, the gap generally widens as load approaches each workload’s service knee because queue-aware routing prevents requests from accumulating behind a small set of busy NDP workers. Second, higher skew increases the opportunity for page actions. For Masstree, G UTENBERG performs similarly to or better than PIMCloud under near-uniform access, but gains a clear advantage once a hot set emerges. CPU assistance further improves performance by executing requests whose pages would otherwise incur costly remote accesses or replica maintenance. Across both primary services, G UTENBERG reduces end-to-end average latency by up to 80.4%. Takeaway. Queue-aware routing avoids overloaded NDP workers under high load. History-guided page actions adapt to stable access skew. CPU assistance handles pages that routing and placement alone cannot serve efficiently. Fig. 7 shows that the improvements also extend to tail latency. G UTENBERG lowers p99 latency across both representative settings, with an end-to-end tail-latency reduction of up to 85.8%.

Method

HBM

UPMEM

PIMCloud ABNDP G UTENBERG-NDP G UTENBERG

1.00 1.09 1.13 0.47

1.00 1.12 0.93 0.61

1.27 ms 16 K

2.59 ms 8K

Base p99 QPS

PIMCloud

ABNDP

Gutenberg

1.0 0.5

−77%

−86%

0.0

Silo Base: 2.33 ms

Masstree Base: 14.54 ms

Fig. 7: End-to-end P99 latency at highest measured load in two representative settings, normalized to the PIMCloud run: Silo (α = .80, 30K) and Masstree (α = .80, 120K). The base in the labels are absolute PIMCloud p99 values. Labels show the G UTENBERG reduction; lower is better.

As shown in Table IV, the mechanisms contribute differently across workloads and operating points. Queue-aware routing (−Q) is most important when requests concentrate on a small number of NDP units. Page placement (−P ) and delta buffering (−∆) preserve this routing flexibility by reducing remote accesses and avoiding eager full-page synchronization. In Fig. 8, direct full-page synchronization is faster at 2% writes; from 5% through 20%, delta buffering lowers p99 by

B. Component Ablation of Contributions We evaluate the contribution of each design component by removing it individually from our full G UTENBERG design.

5.4–12.0%. Normalized mean

A→B

Takeaway. Routing and placement shape locality across load and skew. Once writes become frequent, delta buffering reduces synchronization cost and CPU assistance accelerates pages that are costly to replicate.

1.3

B→A

1.21x

1.2

1.0

0.8 1

100-request windows after shift

C. Performance across Different Hardware Profiles

Fig. 9: Feedback-guided page actions adapt to phase changes. Mean end-to-end latency over 100-request windows, normalized to the same-seed steady-state mean for each phase; lower is better. Lines show the mean across three seeds, and shading shows one standard error.

To test whether the control policy depends on one particular balance of compute and memory resources, we instantiate two organizations around the same Ramulator-calibrated timing core. The HBM-PIM-like profile follows a compact, high-bandwidth organization motivated by Samsung HBMPIM [43]: 16 logical stacks contain 32 1.172-GHz PIM units, with one controller per stack, a 307-Gb/s remote link, and four CPU–PIM ports. The UPMEM-like profile follows the 128DPU DIMM organization and low-frequency in-order cores of UPMEM [14], [81]: 128 450-MHz units, eight controllers per logical stack, a 19-Gb/s remote link, and two CPU– PIM ports. These profiles change worker count by 4× and remote-link bandwidth by more than 16×, while keeping the workload and controller policy fixed. Each column in Table V compares methods at matched operating points (16 KQPS for HBM-PIM-like and 8 KQPS for UPMEM-like) under Zipf0.80. Each method is normalized to the same-profile, sameskew PIMCloud run.

The two transition directions converge at different rates because they replace different page sets. A → B reaches 0.99× its phase-specific steady-state mean at window 10, while B → A declines from a 1.21× peak to 1.02× by window 14. Takeaway. Profiling, online feedback, and page actions continuously adapt to workload changes, while history-aware prediction supplies candidate pages as soon as the active phase is identified and brings transition latency within 2.5% of the phase-specific steady state by windows 10–14. E. Mixed Services: Isolation and Fair QoS Using the same scheduler, we co-schedule Silo with Masstree. The scheduler operates on per-request service-cycle traces under common arrival patterns and resource budgets, preserving routing, borrowing, and fairness decisions. Each service has six persistent logical users. Within each service, one heavy user generates 50% of the offered requests, while each of the five light users generates 10%. Each service is guaranteed 50% of the service-cycle capacity and may borrow the other service’s unused share. The total offered load is set to 0.8 of the knee under the same resource budget. For normalization, each baseline uses the same service, arrival pattern, and request order with the same 50% capacity allocation but without borrowing. The solo p99 bases are 760,919 and 760,375 scheduler ticks for Silo/Masstree. We compare a locality-first unaware greedy scheduler with our servicethen-user hierarchical elastic scheduler (§III-D). We define a starvation window as any interval of 100 global completions in which a continuously backlogged user completes no requests. The service- and user-level results reveal the same scheduling problem. Locality-first greedy scheduling gives early users short queues but allows later light users to accumulate delay, producing high service-level tail latency despite similar total goodput. Hierarchical elastic scheduling first protects each service’s guaranteed share and then distributes that share among its heavy and light users. Idle capacity can still be borrowed, but borrowed work does not reduce the service’s future guaranteed share. For Silo+Masstree, this policy eliminates

The hardware balance changes how strongly each mechanism contributes. On the high-bandwidth profile, G UTENBERG overlaps helper execution with PIM service and cuts end-toend p99 by 53%. On the UPMEM-like profile, G UTENBERGNDP reduces p99 by 7%, while CPU collaboration extends the reduction to 39%. The same controller and page policy therefore improve tail latency across both organizations despite their different worker counts and link bandwidths. Takeaway. The feedback-driven controller remains effective across a fourfold change in worker count and more than a 16fold change in remote bandwidth, while CPU collaboration further reduces tail latency on both hardware profiles.

D. Adaptation to Workload Changes Our controller adapts to workload changes through a closed feedback loop. Page profiling captures current access distributions, online feedback identifies pages that become hot or write-intensive, and page actions update their migration and replication states. History-aware prediction further uses page rankings learned from earlier phases to identify likely migration/replication targets at the start of transitions. Fig. 9 shows how quickly this process adapts on three held-out traces.

Unaware greedy

1.5

1.0

0.5

0.0

Hierarchical

PIMCloud

(b) Silo+Masstree: users 2.0 1.5 1.0 0.5

Masstree

Gutenberg-NDP

Gutenberg

1.5 1.0

upper NI margin

0.5 0.0 Xapian 4.32 ms

0.0 Silo

ABNDP

Normalized p99 latency Ratio to PIMCloud

Normalized user p99

Normalized p99

(a) Silo+Masstree: service

S0 S1 S2 S3 S4 S5 M0M1M2M3M4M5

Moses 7.89 ms

Sphinx 6.77 s

Img-DNN 14.45 ms

Shore 7.59 ms

PIMCloud end-to-end p99 shown below each service

Fig. 10: Mixed-service orchestration isolation and fairness. End-to-end p99 normalized to same-budget solo p99 at the 0.8 knee; 1.0 is parity and lower is better. Left: service-level p99. Right: one 50%-load heavy user (index 0) and five 10%-load users (indices 1–5) per service.

Fig. 11: Tail latency across additional services. End-to-end p99 is normalized to the matched PIMCloud run. The dashed line marks 1.05. Lower is better. improves on PIMCloud across all five services. G UTENBERG also outperforms ABNDP on Moses and lowers p99 across all five services, with the largest reduction of 46.9% on Shore. Sphinx retains the NDP path and matches G UTENBERG-NDP, showing that adaptive execution applies CPU help where it contributes and preserves NDP execution for long speech requests. All methods sustain the full fixed-SLO goodput on Xapian, Moses, Sphinx, and Shore. For Img-DNN, both G UTENBERGNDP and G UTENBERG improve SLO goodput over PIMCloud, by 12.2% and 16.3%, respectively.

all 114,389 starvation windows, while keeping both services below their same-budget standalone p99 latency. Takeaway. Separating service isolation from per-user fairness allows idle capacity to be borrowed without letting a heavy service monopolize other services’ guaranteed share. F. Formal Verification of CPU–NDP Coordination We model-check the coordination state machine (§III-B3) using TLC 2.19 [89]. The model contains 14 state variables and 10 atomic actions that interleave request service with replica, delta, migration, and CPU-ownership transitions. Routing may choose any legal CPU or NDP target, while placement changes require the page to be drained, making correctness independent of the performance policy.

Takeaway. Feedback-directed placement remains effective across diverse services, while adaptive CPU execution selects the faster CPU or NDP path for each workload. V. C ONCLUSION

TABLE VI: TLC model-checking results. M and U denote managed and unmanaged pages. Check

We presented G UTENBERG, a CPU+NDP system that jointly manages request routing, page placement, writable replication, and CPU assistance for mutable cloud services. Across seven services, G UTENBERG reduces average and p99 latency by up to 80.4% and 85.8%, respectively. G UTENBERG also adapts to workload changes and improves service isolation and fairness, showing the benefit of jointly managing computation, data movement, and mutable state.

Bounded instance States (distinct/generated) Result

Safety 3 NDP; 2M+1U Liveness 2 NDP; 1M+1U

1,927,036 / 10,785,764 5,582 / 17,060

9/9 hold; 19 s 2/2 hold; 2 s

Table VI reports two exhaustive runs. The safety run reaches depth 21 and verifies 9 invariants covering state consistency, unique write authority, legal replica reads, managed-page scope, and resource bounds. The liveness run reaches depth 14 and verifies under weak fairness that queues drain and pagestate transitions finish within the bounded policy-mutation budget. TLC found no violations of the specified safety or liveness properties in either bounded configuration. Witness properties also reached both the delta-replica and CPU-owned states, confirming coverage of both coordination paths. These runs verify the coordination invariants and bounded progress in the checked configurations. Runtime audits further check request identity, stale reads, routing, and traffic.

R EFERENCES [1] J. Ahn, S. Hong, S. Yoo, O. Mutlu, and K. Choi, “A scalable processing-in-memory accelerator for parallel graph processing,” in 2015 ACM/IEEE 42nd Annual International Symposium on Computer Architecture (ISCA), 2015, pp. 105–117. [2] T. Assylbekov, M. Yu, J. Park, M. Kim, S. Kim, and J. Lee, “Spima: Scalable and cost-efficient sparse matrix multiplication via processing in dram array,” in 2025 IEEE/ACM International Conference On Computer Aided Design (ICCAD), 2025, pp. 1–8. [3] M. Barkhordar, A. Tabatabaeian, M. Sadrosadati, C. Giannoula, J. Gómez-Luna, I. El Hajj, O. Mutlu, and A. R. Alameldeen, “ALPHAPIM: Analysis of linear algebraic processing for high-performance graph applications on a real processing-in-memory system,” 2026. [4] S. Brin and L. Page, “The anatomy of a large-scale hypertextual web search engine,” Computer Networks and ISDN Systems, vol. 30, no. 1, pp. 107–117, 1998, proceedings of the Seventh International World Wide Web Conference. [Online]. Available: https://doi.org/10.1016/S01697552(98)00110-X

G. Coverage Across Additional TailBench Services Fig. 11 extends to search, translation, speech, image inference, and other OLTP services. G UTENBERG-NDP matches or

[5] S. Cai, B. Tian, H. Zhang, and M. Gao, “Pimpam: Efficient graph pattern matching on real processing-in-memory hardware,” Proc. ACM Manag. Data, vol. 2, no. 3, May 2024. [Online]. Available: https://doi.org/10.1145/3654964 [6] S. Chen, C. Delimitrou, and J. F. Martı́nez, “Parties: Qos-aware resource partitioning for multiple interactive services,” in Proceedings of the Twenty-Fourth International Conference on Architectural Support for Programming Languages and Operating Systems, ser. ASPLOS ’19. New York, NY, USA: Association for Computing Machinery, 2019, pp. 107–120. [Online]. Available: https://doi.org/10.1145/3297858.3304005 [7] S. Chen, Y. Jiang, C. Delimitrou, and J. F. Martı́nez, “Pimcloud: Qosaware resource management of latency-critical applications in clouds with processing-in-memory,” in 2022 IEEE International Symposium on High-Performance Computer Architecture (HPCA), 2022, pp. 1086– 1099. [8] Y. Chen, J. Shu, Y. Shen, L. Huang, and H. Mei, “Rearchitecting the thread model of in-memory key-value stores with utps,” in Proceedings of the ACM SIGOPS 31st Symposium on Operating Systems Principles, ser. SOSP ’25. New York, NY, USA: Association for Computing Machinery, 2025, pp. 1099–1114. [Online]. Available: https://doi.org/10.1145/3731569.3764794 [9] Y. Choi, J. Kim, and M. Rhu, “Hera: A heterogeneity-aware multi-tenant inference server for personalized recommendations,” in Proceedings of the 34th International Conference on Parallel Architectures and Compilation Techniques, ser. PACT ’25, 2025, pp. 320–332. [10] B. F. Cooper, A. Silberstein, E. Tam, R. Ramakrishnan, and R. Sears, “Benchmarking cloud serving systems with ycsb,” in Proceedings of the 1st ACM Symposium on Cloud Computing, ser. SoCC ’10. New York, NY, USA: Association for Computing Machinery, 2010, pp. 143–154. [Online]. Available: https://doi.org/10.1145/1807128.1807152 [11] G. DeCandia, D. Hastorun, M. Jampani, G. Kakulapati, A. Lakshman, A. Pilchin, S. Sivasubramanian, P. Vosshall, and W. Vogels, “Dynamo: amazon’s highly available key-value store,” in Proceedings of Twenty-First ACM SIGOPS Symposium on Operating Systems Principles, ser. SOSP ’07. New York, NY, USA: Association for Computing Machinery, 2007, pp. 205–220. [Online]. Available: https://doi.org/10.1145/1294261.1294281 [12] C. Delimitrou and C. Kozyrakis, “Paragon: Qos-aware scheduling for heterogeneous datacenters,” in Proceedings of the Eighteenth International Conference on Architectural Support for Programming Languages and Operating Systems, ser. ASPLOS ’13. New York, NY, USA: Association for Computing Machinery, 2013, pp. 77–88. [Online]. Available: https://doi.org/10.1145/2451116.2451125 [13] C. Delimitrou and C. Kozyrakis, “Quasar: resource-efficient and qosaware cluster management,” in Proceedings of the 19th International Conference on Architectural Support for Programming Languages and Operating Systems, ser. ASPLOS ’14. New York, NY, USA: Association for Computing Machinery, 2014, pp. 127–144. [Online]. Available: https://doi.org/10.1145/2541940.2541941 [14] F. Devaux, “The true processing in memory accelerator,” in 2019 IEEE Hot Chips 31 Symposium (HCS). IEEE Computer Society, 2019, pp. 1–24. [15] S. Diab, A. Nassereldine, M. Alser, J. Gómez Luna, O. Mutlu, and I. El Hajj, “A framework for high-throughput sequence alignment using real processing-in-memory systems,” Bioinformatics, vol. 39, no. 5, p. btad155, 05 2023. [Online]. Available: https: //doi.org/10.1093/bioinformatics/btad155 [16] DragonflyDB, “Dragonfly: A modern replacement for Redis and Memcached,” https://github.com/dragonflydb/dragonfly, 2026, accessed: 2026-07-27. [17] A. Ghodsi, M. Zaharia, B. Hindman, A. Konwinski, S. Shenker, and I. Stoica, “Dominant resource fairness: Fair allocation of multiple resource types,” in 8th USENIX Symposium on Networked Systems Design and Implementation (NSDI 11). Boston, MA: USENIX Association, Mar. 2011. [Online]. Available: https://www.usenix.org/conference/nsdi11/dominantresource-fairness-fair-allocation-multiple-resource-types [18] C. Giannoula, I. Fernandez, J. G. Luna, N. Koziris, G. Goumas, and O. Mutlu, “Sparsep: Towards efficient sparse matrix vector multiplication on real processing-in-memory architectures,” Proc. ACM Meas. Anal. Comput. Syst., vol. 6, no. 1, Feb. 2022. [Online]. Available: https://doi.org/10.1145/3508041 [19] C. Giannoula, P. Yang, I. Fernandez, J. Yang, S. Durvasula, Y. X. Li, M. Sadrosadati, J. G. Luna, O. Mutlu, and G. Pekhimenko, “Pygim: An

efficient graph neural network library for real processing-in-memory architectures,” Proc. ACM Meas. Anal. Comput. Syst., vol. 8, no. 3, Dec. 2024. [Online]. Available: https://doi.org/10.1145/3700434 [20] J. Gu, Y. Lee, Y. Zhang, M. Chowdhury, and K. G. Shin, “Efficient memory disaggregation with infiniswap,” in 14th USENIX Symposium on Networked Systems Design and Implementation (NSDI 17). Boston, MA: USENIX Association, Mar. 2017, pp. 649–667. [Online]. Available: https://www.usenix.org/conference/nsdi17/technical-sessions/ presentation/gu [21] Y. Gu, A. Khadem, S. Umesh, N. Liang, X. Servot, O. Mutlu, R. Iyer, and R. Das, “Pim is all you need: A cxl-enabled gpu-free system for large language model inference,” in Proceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2, ser. ASPLOS ’25. New York, NY, USA: Association for Computing Machinery, 2025, p. 862–881. [Online]. Available: https://doi.org/10.1145/3676641.3716267 [22] U. Gupta, C.-J. Wu, X. Wang, M. Naumov, B. Reagen, D. Brooks, B. Cottel, K. Hazelwood, M. Hempstead, B. Jia, H.-H. S. Lee, A. Malevich, D. Mudigere, M. Smelyanskiy, L. Xiong, and X. Zhang, “The architectural implications of facebook’s dnn-based personalized recommendation,” in Proceedings of the IEEE International Symposium on High Performance Computer Architecture, ser. HPCA ’20, 2020, pp. 488–501. [23] M. E. Haque, Y. h. Eom, Y. He, S. Elnikety, R. Bianchini, and K. S. McKinley, “Few-to-many: Incremental parallelism for reducing tail latency in interactive services,” SIGARCH Comput. Archit. News, vol. 43, no. 1, pp. 161–175, Mar. 2015. [Online]. Available: https://doi.org/10.1145/2786763.2694384 [24] B. Hindman, A. Konwinski, M. Zaharia, A. Ghodsi, A. D. Joseph, R. Katz, S. Shenker, and I. Stoica, “Mesos: A platform for Fine-Grained resource sharing in the data center,” in 8th USENIX Symposium on Networked Systems Design and Implementation (NSDI 11). Boston, MA: USENIX Association, Mar. 2011. [Online]. Available: https://www.usenix.org/conference/nsdi11/mesosplatform-fine-grained-resource-sharing-data-center [25] C.-H. Hsu, Y. Zhang, M. A. Laurenzano, D. Meisner, T. Wenisch, J. Mars, L. Tang, and R. G. Dreslinski, “Adrenaline: Pinpointing and reining in tail queries with quick voltage boosting,” in 2015 IEEE 21st International Symposium on High Performance Computer Architecture (HPCA), 2015, pp. 271–282. [26] Y. Huang, H. Chen, N. Ni, Y. Sun, V. Chidambaram, D. Tang, and E. Witchel, “Tigon: A distributed database for a CXL pod,” in 19th USENIX Symposium on Operating Systems Design and Implementation (OSDI 25). Boston, MA: USENIX Association, Jul. 2025, pp. 109–128. [Online]. Available: https://www.usenix.org/ conference/osdi25/presentation/huang-yibo [27] J. Jeddeloh and B. Keeth, “Hybrid memory cube new dram architecture increases density and performance,” in 2012 Symposium on VLSI Technology (VLSIT), 2012, pp. 87–88. [28] N. P. Jouppi, C. Young, N. Patil, D. Patterson, G. Agrawal, R. Bajwa, S. Bates, S. Bhatia, N. Boden, A. Borchers, R. Boyle, P.-l. Cantin, C. Chao, C. Clark, J. Coriell, M. Daley, M. Dau, J. Dean, B. Gelb, T. V. Ghaemmaghami, R. Gottipati, W. Gulland, R. Hagmann, C. R. Ho, D. Hogberg, J. Hu, R. Hundt, D. Hurt, J. Ibarz, A. Jaffey, A. Jaworski, A. Kaplan, H. Khaitan, D. Killebrew, A. Koch, N. Kumar, S. Lacy, J. Laudon, J. Law, D. Le, C. Leary, Z. Liu, K. Lucke, A. Lundin, G. MacKean, A. Maggiore, M. Mahony, K. Miller, R. Nagarajan, R. Narayanaswami, R. Ni, K. Nix, T. Norrie, M. Omernick, N. Penukonda, A. Phelps, J. Ross, M. Ross, A. Salek, E. Samadiani, C. Severn, G. Sizikov, M. Snelham, J. Souter, D. Steinberg, A. Swing, M. Tan, G. Thorson, B. Tian, H. Toma, E. Tuttle, V. Vasudevan, R. Walter, W. Wang, E. Wilcox, and D. H. Yoon, “In-datacenter performance analysis of a tensor processing unit,” SIGARCH Comput. Archit. News, vol. 45, no. 2, pp. 1–12, Jun. 2017. [Online]. Available: https://doi.org/10.1145/3140659.3080246 [29] H. Kang, P. B. Gibbons, G. E. Blelloch, L. Dhulipala, Y. Gu, and C. McGuffey, “The processing-in-memory model,” in Proceedings of the 33rd ACM Symposium on Parallelism in Algorithms and Architectures, 2021, pp. 295–306. [30] H. Kang, Y. Zhao, K. Agrawal, Y. Wu, and P. B. Gibbons, “Nonclairvoyant scheduling for processing-in-memory,” in Proceedings of the 38th ACM Symposium on Parallelism in Algorithms and Architectures, ser. SPAA ’26. New York, NY, USA: Association

for Computing Machinery, 2026, pp. 392–404. [Online]. Available: https://doi.org/10.1145/3816782.3819200 [31] H. Kang, Y. Zhao, G. E. Blelloch, L. Dhulipala, Y. Gu, C. McGuffey, and P. B. Gibbons, “Pim-tree: A skew-resistant index for processing-inmemory,” Proc. VLDB Endow., vol. 16, no. 4, pp. 946–958, dec 2022. [Online]. Available: https://doi.org/10.14778/3574245.3574275 [32] H. Kang, Y. Zhao, G. E. Blelloch, L. Dhulipala, Y. Gu, C. McGuffey, and P. B. Gibbons, “Pim-tree: A skew-resistant index for processingin-memory (abstract),” in Proceedings of the 2023 ACM Workshop on Highlights of Parallel Computing, ser. HOPC ’23. New York, NY, USA: Association for Computing Machinery, 2023, p. 13–14. [Online]. Available: https://doi.org/10.1145/3597635.3598029 [33] H. Kang, Y. Zhao, G. E. Blelloch, L. Dhulipala, Y. Gu, C. McGuffey, and P. B. Gibbons, “Pim-trie: A skew-resistant trie for processing-inmemory,” in Proceedings of the 35th ACM Symposium on Parallelism in Algorithms and Architectures, ser. SPAA ’23. New York, NY, USA: Association for Computing Machinery, 2023, pp. 1–14. [Online]. Available: https://doi.org/10.1145/3558481.3591070 [34] H. Kang, Y. Zhao, G. E. Blelloch, L. Dhulipala, Y. Gu, C. McGuffey, and P. B. Gibbons, “Pim-tree: A skew-resistant index for processingin-memory,” The VLDB Journal, vol. 34, no. 6, p. 66, 2025. [Online]. Available: https://doi.org/10.1007/s00778-025-00937-5 [35] T. Kang, G. Choi, T. Suh, and G. Koo, “Sparsepim: An efficient hbm-based pim architecture for sparse matrix-vector multiplications,” in Proceedings of the 39th ACM International Conference on Supercomputing, ser. ICS ’25. New York, NY, USA: Association for Computing Machinery, 2025, p. 495–512. [Online]. Available: https://doi.org/10.1145/3721145.3735111 [36] H. Kasture and D. Sanchez, “Tailbench: a benchmark suite and evaluation methodology for latency-critical applications,” in 2016 IEEE International Symposium on Workload Characterization (IISWC), 2016, pp. 1–10. [37] L. Ke, U. Gupta, B. Y. Cho, D. Brooks, V. Chandra, U. Diril, A. Firoozshahian, K. Hazelwood, B. Jia, H.-H. S. Lee, M. Li, B. Maher, D. Mudigere, M. Naumov, M. Schatz, M. Smelyanskiy, X. Wang, B. Reagen, C.-J. Wu, M. Hempstead, and X. Zhang, “Recnmp: Accelerating personalized recommendation with near-memory processing,” in 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA), 2020, pp. 790–803. [38] A. Kemper and T. Neumann, “Hyper: A hybrid oltp&olap main memory database system based on virtual memory snapshots,” in 2011 IEEE 27th International Conference on Data Engineering, 2011, pp. 195–206. [39] D. Kim, T. Kim, I. Hwang, T. Park, H. Kim, Y. Kim, and Y. Park, “Virtual pim: Resource-aware dynamic dpu allocation and workload scheduling framework for multi-dpu pim architecture,” in 2023 32nd International Conference on Parallel Architectures and Compilation Techniques (PACT), 2023, pp. 112–123. [40] H. Kim, T. Kim, T. Park, D. Kim, Y. Yu, H. Kim, and Y. Park, “Accelerating llms using an efficient gemm library and target-aware optimizations on real-world pim devices,” in Proceedings of the 23rd ACM/IEEE International Symposium on Code Generation and Optimization, ser. CGO ’25. New York, NY, USA: Association for Computing Machinery, 2025, p. 225–240. [Online]. Available: https://doi.org/10.1145/3696443.3708953 [41] H. Kim, Y. Zhao, A. Pavlo, and P. B. Gibbons, “No cap, this memory slaps: Breaking through the memory wall of transactional database systems with processing-in-memory,” Proc. VLDB Endow., vol. 18, no. 11, pp. 4241–4254, Jul. 2025. [Online]. Available: https://doi.org/10.14778/3749646.3749690 [42] Y. Kim, W. Yang, and O. Mutlu, “Ramulator: A fast and extensible dram simulator,” IEEE Computer Architecture Letters, vol. 15, no. 1, pp. 45–49, 2016. [43] Y.-C. Kwon, S. H. Lee, J. Lee, S.-H. Kwon, J. M. Ryu, J.-P. Son, O. Seongil, H.-S. Yu, H. Lee, S. Y. Kim, Y. Cho, J. G. Kim, J. Choi, H.-S. Shin, J. Kim, B. Phuah, H. Kim, M. J. Song, A. Choi, D. Kim, S. Kim, E.-B. Kim, D. Wang, S. Kang, Y. Ro, S. Seo, J. Song, J. Youn, K. Sohn, and N. S. Kim, “25.4 a 20nm 6gb function-in-memory dram, based on hbm2 with a 1.2tflops programmable computing unit using bank-level parallelism, for machine learning applications,” in 2021 IEEE International Solid- State Circuits Conference (ISSCC), vol. 64, 2021, pp. 350–352. [44] L. Lamport, “The temporal logic of actions,” ACM Trans. Program. Lang. Syst., vol. 16, no. 3, pp. 872–923, May 1994. [Online]. Available: https://doi.org/10.1145/177492.177726

[45] L. Lamport, Specifying systems. Addison-Wesley Boston, 2002, vol. 388. [46] D. U. Lee, K. W. Kim, K. W. Kim, H. Kim, J. Y. Kim, Y. J. Park, J. H. Kim, D. S. Kim, H. B. Park, J. W. Shin, J. H. Cho, K. H. Kwon, M. J. Kim, J. Lee, K. W. Park, B. Chung, and S. Hong, “25.2 a 1.2v 8gb 8-channel 128gb/s high-bandwidth memory (hbm) stacked dram with effective microbump i/o test methods using 29nm process and tsv,” in 2014 IEEE International Solid-State Circuits Conference Digest of Technical Papers (ISSCC), 2014, pp. 432–433. [47] S. Lee, C. Lim, J. Choi, H. Choi, C. Lee, Y. Park, K. Park, H. Kim, and Y. Kim, “Spid-join: A skew-resistant processing-in-dimm join algorithm exploiting the bank- and rank-level parallelisms of dimms,” Proc. ACM Manag. Data, vol. 2, no. 6, Dec. 2024. [Online]. Available: https://doi.org/10.1145/3698827 [48] H. Li, D. S. Berger, L. Hsu, D. Ernst, P. Zardoshti, S. Novakovic, M. Shah, S. Rajadnya, S. Lee, I. Agarwal, M. D. Hill, M. Fontoura, and R. Bianchini, “Pond: Cxl-based memory pooling systems for cloud platforms,” in Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2, ser. ASPLOS 2023. New York, NY, USA: Association for Computing Machinery, 2023, pp. 574–587. [Online]. Available: https://doi.org/10.1145/3575693.3578835 [49] Y. Li, B. Tian, Y. Ren, and M. Gao, “Stream-based data placement for near-data processing with extended memory,” in 2024 57th IEEE/ACM International Symposium on Microarchitecture (MICRO), 2024, pp. 1648–1662. [50] H. Lim, M. Kaminsky, and D. G. Andersen, “Cicada: Dependably fast multi-core in-memory transactions,” in Proceedings of the 2017 ACM International Conference on Management of Data, ser. SIGMOD ’17. New York, NY, USA: Association for Computing Machinery, 2017, pp. 21–35. [Online]. Available: https://doi.org/10.1145/3035918.3064015 [51] Q. Lin, C. Zhang, Íñigo Goiri, A. Akella, R. Bianchini, and J. Stojkovic, “Atumai: A principled framework for agentic generation of datacenter control-plane policies,” 2026. [Online]. Available: https://arxiv.org/abs/2608.02569 [52] D. Lo, L. Cheng, R. Govindaraju, P. Ranganathan, and C. Kozyrakis, “Heracles: Improving resource efficiency at scale,” in Proceedings of the 42nd Annual International Symposium on Computer Architecture, ser. ISCA ’15, 2015. [53] K. Mahajan, A. Balasubramanian, A. Singhvi, S. Venkataraman, A. Akella, A. Phanishayee, and S. Chawla, “Themis: Fair and efficient GPU cluster scheduling,” in 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI 20). Santa Clara, CA: USENIX Association, Feb. 2020, pp. 289–304. [Online]. Available: https://www.usenix.org/conference/nsdi20/presentation/mahajan [54] H. Mao, M. Alser, M. Sadrosadati, C. Firtina, A. Baranwal, D. S. Cali, A. Manglik, N. A. Alserr, and O. Mutlu, “Genpip: In-memory acceleration of genome analysis via tight integration of basecalling and read mapping,” in 2022 55th IEEE/ACM International Symposium on Microarchitecture (MICRO), 2022, pp. 710–726. [55] Y. Mao, E. Kohler, and R. T. Morris, “Cache craftiness for fast multicore key-value storage,” in Proceedings of the 7th ACM European Conference on Computer Systems, ser. EuroSys ’12. New York, NY, USA: Association for Computing Machinery, 2012, pp. 183–196. [Online]. Available: https://doi.org/10.1145/2168836.2168855 [56] K. Matsushima, Y. Okoshi, M. Motomura, and D. Fujiki, “Aqpim: Breaking the pim capacity wall for llms with in-memory activation quantization,” in 2026 IEEE International Symposium on High Performance Computer Architecture (HPCA), 2026, pp. 1–17. [57] J. Mohoney, D. Sarda, M. Tang, S. R. Chowdhury, A. Pacaci, I. F. Ilyas, T. Rekatsinas, and S. Venkataraman, “Quake: Adaptive indexing for vector search,” in 19th USENIX Symposium on Operating Systems Design and Implementation (OSDI 25). Boston, MA: USENIX Association, Jul. 2025, pp. 153–169. [Online]. Available: https://www.usenix.org/conference/osdi25/presentation/mohoney [58] W. Moina-Rivera, M. Garcia-Pineda, J. Gutiérrez-Aguado, and J. M. Alcaraz-Calero, “Cloud media video encoding: Review and challenges,” Multimedia Tools and Applications, vol. 83, pp. 81 231–81 278, 2024. [59] O. Mutlu, S. Ghose, J. Gómez-Luna, and R. Ausavarungnirun, A Modern Primer on Processing in Memory. Singapore: Springer Nature Singapore, 2023, pp. 171–243. [Online]. Available: https: //doi.org/10.1007/978-981-16-7487-7 7 [60] D. Narayanan, K. Santhanam, F. Kazhamiaka, A. Phanishayee, and M. Zaharia, “Heterogeneity-Aware cluster scheduling policies

for deep learning workloads,” in 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). USENIX Association, Nov. 2020, pp. 481–498. [Online]. Available: https: //www.usenix.org/conference/osdi20/presentation/narayanan-deepak [61] R. Nishtala, H. Fugal, S. Grimm, M. Kwiatkowski, H. Lee, H. C. Li, R. McElroy, M. Paleczny, D. Peek, P. Saab, D. Stafford, T. Tung, and V. Venkataramani, “Scaling memcache at facebook,” in Proceedings of the 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI), 2013, pp. 385–398. [Online]. Available: https://www.usenix.org/conference/nsdi13/technical-sessions/ presentation/nishtala [62] R. Nishtala, P. Carpenter, V. Petrucci, and X. Martorell, “Hipster: Hybrid task manager for latency-critical cloud workloads,” in 2017 IEEE International Symposium on High Performance Computer Architecture (HPCA), 2017, pp. 409–420. [63] D. Pacheco, L. Sousa, and A. Ilic, “PRISM: Processing-in-memory sparse MTTKRP for tensor decomposition acceleration,” 2026. [64] J. Park, J. Choi, K. Kyung, M. J. Kim, Y. Kwon, N. S. Kim, and J. H. Ahn, “Attacc! unleashing the power of pim for batched transformerbased generative model inference,” in Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2, ser. ASPLOS ’24. New York, NY, USA: Association for Computing Machinery, 2024, p. 103–119. [Online]. Available: https://doi.org/10.1145/3620665.3640422 [65] S. Qi, L. Guo, Y. Lu, C. Zhang, D. Yang, G. Chen, X. Liu, C. Shen, Y. Xu, G. Li et al., “The LDBC financial benchmark: Transaction workload,” Proceedings of the VLDB Endowment, vol. 18, no. 9, pp. 3007–3020, 2025. [Online]. Available: https: //www.vldb.org/pvldb/vol18/p3007-qi.pdf [66] H. Qiu, S. S. Banerjee, S. Jha, Z. T. Kalbarczyk, and R. K. Iyer, “FIRM: An intelligent fine-grained resource management framework for SLO-Oriented microservices,” in 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). USENIX Association, Nov. 2020, pp. 805–825. [Online]. Available: https://www.usenix.org/conference/osdi20/presentation/qiu [67] X. Qiu, W. Cen, Z. Qian, Y. Peng, Y. Zhang, X. Lin, and J. Zhou, “Real-time constrained cycle detection in large dynamic graphs,” Proc. VLDB Endow., vol. 11, no. 12, pp. 1876–1888, Aug. 2018. [Online]. Available: https://doi.org/10.14778/3229863.3229874 [68] Z. Ruan, M. Schwarzkopf, M. K. Aguilera, and A. Belay, “AIFM: HighPerformance, Application-Integrated far memory,” in 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). USENIX Association, Nov. 2020, pp. 315–332. [Online]. Available: https://www.usenix.org/conference/osdi20/presentation/ruan [69] D. Sanchez and C. Kozyrakis, “Zsim: fast and accurate microarchitectural simulation of thousand-core systems,” in Proceedings of the 40th Annual International Symposium on Computer Architecture, ser. ISCA ’13. New York, NY, USA: Association for Computing Machinery, 2013, pp. 475–486. [Online]. Available: https://doi.org/10.1145/2485922.2485963 [70] C. Shin, J. Song, S. Na, J. Sung, H. Jang, and J. Lee, “Fala: Localityaware pim-host cooperation for graph processing with fine-grained column access,” in Proceedings of the 58th IEEE/ACM International Symposium on Microarchitecture, ser. MICRO ’25. New York, NY, USA: Association for Computing Machinery, 2025, p. 1520–1534. [Online]. Available: https://doi.org/10.1145/3725843.3756127 [71] Y. Shin, J. Park, S. Cho, and H. Sung, “Pimflow: Compiler and runtime support for cnn models on processing-in-memory dram,” in Proceedings of the 21st ACM/IEEE International Symposium on Code Generation and Optimization, ser. CGO ’23. New York, NY, USA: Association for Computing Machinery, 2023, p. 249–262. [Online]. Available: https://doi.org/10.1145/3579990.3580009 [72] D. Shue, M. J. Freedman, and A. Shaikh, “Performance isolation and fairness for Multi-Tenant cloud storage,” in 10th USENIX Symposium on Operating Systems Design and Implementation (OSDI 12). Hollywood, CA: USENIX Association, Oct. 2012, pp. 349– 362. [Online]. Available: https://www.usenix.org/conference/osdi12/ technical-sessions/presentation/shue [73] W. A. Simon, L. Yavits, K. Koliogeorgi, Y. Falevoz, Y. Shibuya, D. Lavenier, I. Boybat, K. Zambaku, B. Şahin, M. Sadrosadati, O. Mutlu, A. Sebastian, R. Chikhi, T. B. Consortium, and C. Alkan, “Processingin-memory for genomics workloads,” IEEE Micro, vol. 46, no. 2, pp. 70–80, 2026.

[74] SK hynix, “SK hynix develops PIM, next-generation AI accelerator,” https://news.skhynix.com/sk-hynix-develops-pim-next-generationai-accelerator/, 2022, accessed: 2026-07-10. [75] H. Son, G. Jonatan, X. Wu, H. Cho, K. Shivdikar, J. L. Abellán, A. Joshi, D. Kaeli, and J. Kim, “Pimnet: A domain-specific network for efficient collective communication in scalable pim,” in 2025 IEEE International Symposium on High Performance Computer Architecture (HPCA), 2025, pp. 1557–1572. [76] M. Soysal, K. Koliogeorgi, C. Firtina, N. M. Ghiasi, R. Nadig, H. Mao, G. F. de Oliveira Junior, Y. Liang, K. Zambaku, M. Sadrosadati, and O. Mutlu, “Mars: Processing-in-memory acceleration of raw signal genome analysis inside the storage subsystem,” in Proceedings of the 39th ACM International Conference on Supercomputing, ser. ICS ’25. New York, NY, USA: Association for Computing Machinery, 2025, p. 513–534. [Online]. Available: https://doi.org/10.1145/3721145.3730428 [77] D. Teguia, J. Chen, S. Bitchebe, O. Balmau, and A. Tchana, “vpim: Processing-in-memory virtualization,” in Proceedings of the 25th International Middleware Conference, ser. Middleware ’24. New York, NY, USA: Association for Computing Machinery, 2024, p. 417–430. [Online]. Available: https://doi.org/10.1145/3652892.3700782 [78] B. Tian, Q. Chen, and M. Gao, “Abndp: Co-optimizing data access and load balance in near-data processing,” in Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 3, ser. ASPLOS 2023. New York, NY, USA: Association for Computing Machinery, 2023, pp. 3–17. [Online]. Available: https://doi.org/10.1145/3582016.3582026 [79] Transaction Processing Performance Council, TPC Benchmark C: Standard Specification, Revision 5.11, Transaction Processing Performance Council, Feb. 2010. [Online]. Available: https: //www.tpc.org/tpc documents current versions/pdf/tpc-c v5.11.0.pdf [80] S. Tu, W. Zheng, E. Kohler, B. Liskov, and S. Madden, “Speedy transactions in multicore in-memory databases,” in Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles, ser. SOSP ’13. New York, NY, USA: Association for Computing Machinery, 2013, pp. 18–32. [Online]. Available: https://doi.org/10.1145/2517349.2522713 [81] UPMEM, “Upmem technology,” https://www.upmem.com/technology/, 2026, accessed July 2026. [82] A. Verma, L. Pedrosa, M. Korupolu, D. Oppenheimer, E. Tune, and J. Wilkes, “Large-scale cluster management at google with borg,” in Proceedings of the Tenth European Conference on Computer Systems, ser. EuroSys ’15. New York, NY, USA: Association for Computing Machinery, 2015. [Online]. Available: https://doi.org/10.1145/2741948.2741964 [83] Z. Wang, P. Li, C.-J. M. Liang, F. Wu, and F. Y. Yan, “Autothrottle: A practical Bi-Level approach to resource management for SLOTargeted microservices,” in 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24). Santa Clara, CA: USENIX Association, Apr. 2024, pp. 149–165. [Online]. Available: https://www.usenix.org/conference/nsdi24/presentation/wang-zibo [84] M. Wilkening, U. Gupta, S. Hsia, C. Trippel, C.-J. Wu, D. Brooks, and G.-Y. Wei, “Recssd: near data processing for solid state drive based recommendation inference,” in Proceedings of the 26th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, ser. ASPLOS ’21. New York, NY, USA: Association for Computing Machinery, 2021, pp. 717–729. [Online]. Available: https://doi.org/10.1145/3445814.3446763 [85] Xapian, “Xapian project,” https://xapian.org/. [86] XCENA, “MX1: CXL computational memory,” https://xcena.com/about, 2026, accessed: 2026-07-10. [87] Y. Xia, D. Sharma, Y. Yuan, S. Kundu, and N. Talati, “Modm: Efficient serving for image generation via mixture-of-diffusion models,” in Proceedings of the 31st ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 1, ser. ASPLOS ’26. New York, NY, USA: Association for Computing Machinery, 2025, pp. 163–182. [Online]. Available: https://doi.org/10.1145/3760250.3762220 [88] J. Yang, Y. Yue, and K. V. Rashmi, “A large-scale analysis of hundreds of in-memory key-value cache clusters at twitter,” ACM Trans. Storage, vol. 17, no. 3, Aug. 2021. [Online]. Available: https://doi.org/10.1145/3468521 [89] Y. Yu, P. Manolios, and L. Lamport, “Model checking tla+ specifications,” in Correct Hardware Design and Verification Methods, L. Pierre

and T. Kropf, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 1999, pp. 54–66. [90] Y. Zhang, W. Hua, Z. Zhou, G. E. Suh, and C. Delimitrou, “Sinan: Mlbased and qos-aware resource management for cloud microservices,” in Proceedings of the 26th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, ser. ASPLOS ’21. New York, NY, USA: Association for Computing Machinery, 2021, pp. 167–181. [Online]. Available: https://doi.org/10.1145/3445814.3446693 [91] Y. Zhao, M. Gao, H. Zhang, F. Liu, G. Chen, H. Xian, H. Guan, and L. Jiang, “Pushtap: Pim-based in-memory htap with unified data storage format,” in Proceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 3, ser. ASPLOS ’25. New York, NY, USA: Association for Computing Machinery, 2025, pp. 179–194. [Online]. Available: https://doi.org/10.1145/3676642.3736120 [92] Y. Zhao, H. Kang, Y. Gu, G. E. Blelloch, L. Dhulipala, C. McGuffey, and P. B. Gibbons, “Optimal batch-dynamic kd-trees for processing-inmemory with applications,” in Proceedings of the 37th ACM Symposium on Parallelism in Algorithms and Architectures, ser. SPAA ’25. New York, NY, USA: Association for Computing Machinery, 2025, pp. 350–366. [Online]. Available: https://doi.org/10.1145/3694906.3743318 [93] Y. Zhao, H. Kang, Z. Men, Y. Gu, G. E. Blelloch, L. Dhulipala, C. McGuffey, and P. B. Gibbons, “Pim-zd-tree: A fast space-partitioning index leveraging processing-in-memory,” in Proceedings of the 31st ACM SIGPLAN Annual Symposium on Principles and Practice of Parallel Programming, ser. PPoPP ’26. New York, NY, USA: Association for Computing Machinery, 2026, pp. 480–495. [Online]. Available: https://doi.org/10.1145/3774934.3786411 [94] Y. Zhong, D. S. Berger, C. Waldspurger, R. Wee, I. Agarwal, R. Agarwal, F. Hady, K. Kumar, M. D. Hill, M. Chowdhury, and A. Cidon, “Managing memory tiers with CXL in virtualized environments,” in 18th USENIX Symposium on Operating Systems Design and Implementation (OSDI 24). Santa Clara, CA: USENIX Association, Jul. 2024, pp. 37–56. [Online]. Available: https: //www.usenix.org/conference/osdi24/presentation/zhong-yuhong [95] G. K. Zipf, Human Behavior and the Principle of Least Effort: An Introduction to Human Ecology. Cambridge, MA: Addison-Wesley Press, 1949. [Online]. Available: https://www.mpi.nl/publications/item2407822/human-behaviorand-principle-least-effort-introduction-human-eoclogy

Record · ID 668004 · SHA-256 5c0e2bf336410c68
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.