[Paper Review] FluidMem: Memory as a Service for the Datacenter

Blake Caldwell, Youngbin Im+3 more|arXiv (Cornell University)|Jul 25, 2017

Cloud Computing and Resource Management27 references5 citations

TL;DR

FluidMem introduces a complete Memory as a Service (MaaS) system for datacenters, enabling transparent remote memory access for standard applications via Linux's userfaultfd and hotplug memory mechanisms. It supports unmodified workloads like MongoDB, genome assemblers, Spark, and Graph500, demonstrating that remote memory can be exposed to applications without modification, even when exceeding local physical memory limits.

ABSTRACT

Disaggregating resources in data centers is an emerging trend. Recent work has begun to explore memory disaggregation, but suffers limitations including lack of consideration of the complexity of cloud-based deployment, including heterogeneous hardware and APIs for cloud users and operators. In this paper, we present FluidMem, a complete system to realize disaggregated memory in the datacenter. Going beyond simply demonstrating remote memory is possible, we create an entire Memory as a Service. We define the requirements of Memory as a Service and build its implementation in Linux as FluidMem. We present a performance analysis of FluidMem and demonstrate that it transparently supports remote memory for standard applications such as MongoDB and genome sequencing applications.

Motivation & Objective

• Address the lack of production-ready, cloud-deployable memory disaggregation systems that support heterogeneous hardware and existing cloud APIs.
• Enable transparent remote memory access for scale-up and scale-out applications without application or OS modifications.
• Provide a complete, production-ready implementation of Memory as a Service (MaaS) that supports dynamic memory expansion in VMs.
• Support diverse back-end memory stores (e.g., RAMCloud, key-value stores) and heterogeneous networking in real datacenter environments.
• Expose physical remote memory directly to applications via hotplug, allowing memory-aware optimizations and preventing OOM failures.

Proposed method

• Leverage Linux’s userfaultfd mechanism to handle page faults in userspace, enabling flexible and asynchronous remote memory access without kernel modifications.
• Integrate with the Linux hotplug memory interface to dynamically expand virtual memory in VMs, allowing applications to see and use remote memory as if it were local.
• Design a layered architecture where remote memory is backed by key-value stores (e.g., RAMCloud), abstracting the underlying storage and network stack.
• Support multiple back-end memory stores (three evaluated in the paper) through a pluggable interface, enabling optimization and heterogeneity.
• Use a VM-based deployment model to ensure compatibility with existing cloud infrastructure and avoid application-level changes.
• Implement transparent memory access by inserting the remote memory abstraction at the virtual memory fault handling layer, avoiding interference with application or OS semantics.

Experimental results

Research questions

• RQ1 Can a complete, production-ready Memory as a Service system be built that supports unmodified cloud applications in heterogeneous datacenter environments?
• RQ2 How can remote memory be exposed to applications in a way that allows them to detect and utilize additional capacity without code changes?
• RQ3 What are the performance and scalability characteristics of a user-space-based remote memory system in real-world workloads?
• RQ4 Can remote memory access be made efficient and reliable enough to support memory-intensive, non-distributed workloads like genome assembly and database systems?
• RQ5 How does the system handle dynamic memory expansion and isolation in virtualized cloud environments?

Key findings

• FluidMem successfully enabled MongoDB to use remote memory transparently, allowing it to optimize its internal memory management based on the expanded capacity.
• Genome sequencing applications like SOAPdenovo and Velvet completed full human chromosome 14 assembly on a VM with only 72GB of memory (60GB local, 12GB from FluidMem), a task that would otherwise fail due to memory exhaustion.
• The Graph500 BFS benchmark and Apache Spark executed successfully on FluidMem without modification, demonstrating support for memory-bound, irregular workloads.
• Remote memory access latency was within the 3–5 μs range, meeting the performance threshold identified in prior work as necessary for minimal performance degradation.
• The system achieved transparent memory expansion via hotplug, allowing VMs to dynamically access more physical memory than available on any single node.
• Userfaultfd-based handling enabled support for multiple back-end key-value stores and allowed for concurrent and asynchronous page fault handling, improving scalability and responsiveness.