---
title: 'Memory Operating System: Lifecycle & Policy Controls'
url: https://www.emergentmind.com/topics/memory-operating-system
type: topic
---

# Memory Operating System: Lifecycle & Policy Controls

Searching arXiv for recent and foundational papers on "memory operating system" to ground the article in the provided literature and related work.
A Memory Operating System denotes an operating-system-level or OS-inspired framework in which memory is treated as an explicitly managed, policy-governed system resource rather than as a passive substrate. Across systems research, this term has been used in at least three closely related senses: OS kernels that manage heterogeneous physical memories such as DRAM, NVM, NVMM, SCM, or LtRAM with explicit placement and migration policies; operating-system mechanisms that restructure protection and access to user memory; and, more recently, memory-centric control planes for large language model agents that organize, retrieve, migrate, and govern multiple forms of computational memory [1805.02514], [1703.07725], [2212.12671], [2506.06326], [2507.03724], [2601.02163]. In all of these senses, the central idea is the same: memory is no longer a flat addressable space or a simple retrieval buffer, but a layered, lifecycle-managed object of allocation, scheduling, migration, protection, consolidation, and reclamation.

## 1. Historical and conceptual scope

The emergence of hybrid DRAM–NVM systems was an early catalyst for Memory OS thinking. As Non-Volatile Memories entered main-memory hierarchies, several studies argued that traditional OS memory management was inadequate because it did not account for migration cost, power, endurance, and granularity effects. An OS-level hybrid DRAM–NVM memory manager using dual LRU queues was proposed to reduce unnecessary migrations and only allow migrations that benefit the system in terms of power and performance [1805.02514]. In parallel, the system called *memos* extended OS control over the entire memory hierarchy, including cache, channels, DRAM, and NVM, using kernel-level monitoring and a page migration engine [1703.07725].

A second line of work broadened the term beyond mere placement in heterogeneous hardware. In this view, memory management includes privilege separation and control over who may access memory and under what invariants. MProtect argued that unfettered OS access to user memory is not fundamentally necessary for memory management, and introduced a higher-privilege Guardian that mediates access, page-table updates, exceptions, and semantic access through capabilities [2212.12671]. This reframes a Memory OS as a system in which memory governance includes confidentiality and integrity, not only placement and latency.

A third line emerged from persistent-memory and SCM research. The analysis of POSIX-compliant operating systems in NVM/SCM environments emphasized that synchronization-related system calls such as `poll()`, `futex()`, and `wait4()` remain dominant overheads even on a RAMdisk, suggesting that simply accelerating the storage substrate does not remove kernel-crossing and metadata bottlenecks [1712.07759]. Related work on terabyte-scale NVMM showed that DRAM-oriented allocators become inadequate when zeroing, compaction, and allocation occur over high-latency, high-capacity media [2310.03370]. This suggests that a Memory OS may require redesigning core physical-memory subsystems rather than merely adding a new tier.

More recent work transferred the Memory OS concept into AI systems. MemoryOS introduced a three-tier conversational memory hierarchy—short-term memory, mid-term memory, and long-term personal memory—along with storage, updating, retrieval, and generation modules [2506.06326]. MemOS generalized the concept further by unifying plaintext, activation-based, and parameter-level memories under the MemCube abstraction [2507.03724], [2505.22101]. EverMemOS then defined a self-organizing lifecycle built around MemCells, MemScenes, and a reconstructive retrieval process oriented toward long-horizon reasoning [2601.02163]. Text2Mem added a formal operation language with schema-validated verbs such as Encode, Retrieve, Delete, Merge, Promote, Demote, Split, Lock, and Expire [2509.11145].

Taken together, these works show that “Memory Operating System” is not a single architecture but a family of architectures unified by explicit lifecycle control, policy-aware representation, and system-level governance over memory objects.

## 2. Core design principles

A recurring principle is **hierarchical organization**. In hybrid hardware systems, the hierarchy typically spans fast DRAM and slower but denser NVM or NVMM, sometimes with cache, channel, and bank placement as additional dimensions [1703.07725]. In LLM-oriented systems, the hierarchy spans short-term, mid-term, and long-term stores [2506.06326], or plaintext, activation, and parameter memories [2507.03724], [2505.22101]. The underlying premise is that memory tiers differ in latency, capacity, update cost, and persistence, so allocation policy must account for these trade-offs.

A second principle is **explicit migration or lifecycle transition**. In hybrid DRAM–NVM managers, migrations are triggered by hotness, read/write asymmetry, or inactivity [1805.02514], [1703.07725], [2606.26138]. In MemOS for AI systems, MemCubes can be promoted, demoted, archived, fused, or parameterized according to usage frequency and semantic stability [2507.03724]. EverMemOS formalizes this as a three-phase lifecycle: Episodic Trace Formation, Semantic Consolidation, and Reconstructive Recollection [2601.02163]. Text2Mem makes such transitions first-class operations with explicit invariants [2509.11145].

A third principle is **metadata-rich control**. Hardware-oriented systems track hotness, reuse, read/write dominance, dirty bits, lifetime, and contextual ownership [1703.07725], [2004.04760]. KLOC groups kernel allocations into per-context object maps, where a context is “all kernel objects allocated on behalf of one inode or one socket,” enabling allocation and demotion policies based on active versus inactive contexts [2004.04760]. AI-oriented systems likewise attach timestamps, provenance, ACLs, TTL, priority, versioning, and usage patterns to MemCubes [2507.03724], or use metadata fields in MemCells for timestamps, source pointers, and origin identifiers [2601.02163].

A fourth principle is **governance and invariants**. MProtect enforces two invariants: no OS thread may map or read a sensitive user page in cleartext unless explicitly granted by a capability, and no modification of any page-table frame or interrupt-vector frame is possible without the Guardian’s permission [2212.12671]. Text2Mem similarly defines operation-level semantic invariants such as “cannot delete locked” and constrains promote/demote, expire, merge, and lock semantics through validator and parser stages [2509.11145]. This suggests that Memory OS designs increasingly converge on explicit state machines rather than informal heuristics.

A fifth principle is **minimization of unnecessary movement and kernel crossings**. The dual-LRU hybrid memory scheme avoids blind promotions by using thresholds on read and write counts for only the hottest fraction of the NVM queue [1805.02514]. The POSIX-on-SCM study argues that preserving POSIX-style system-call sequences can remain fundamentally inefficient, especially due to synchronization-related crossings [1712.07759]. In LLM memory systems, sufficiency-guided retrieval in EverMemOS explicitly seeks only the necessary and sufficient context, avoiding indiscriminate expansion [2601.02163].

## 3. OS-level heterogeneous memory management

In hybrid DRAM–NVM operating systems, Memory OS functionality is often expressed through page placement, migration, replacement, and endurance-aware scheduling. One representative design uses two LRU queues, one for DRAM and one for NVM. On a DRAM hit, the page moves to the head of the DRAM-LRU; on an NVM hit, the page moves to the head of the NVM-LRU and may be promoted to DRAM if per-page counters exceed read or write thresholds [1805.02514]. Counters are maintained only for the top fraction of the NVM queue, with typical parameter choices from PARSEC tuning given as `read_window = 5%`, `R_thresh ≈ 10`, `write_window = 10%`, and `W_thresh ≈ 5` [1805.02514]. The lower write threshold reflects the greater benefit of moving write-dominant hot pages into DRAM.

The cost model in such systems explicitly includes migration. The migration cost per page is modeled as
\[
C_{\mathrm{mig}} = t_{r,\mathrm{NVM}} + t_{w,\mathrm{DRAM}}
\]
plus DMA overhead, and AMAT includes DRAM hits, NVM hits, misses, and migration terms [1805.02514]. Power is likewise modeled as a function of DRAM-active accesses, NVM reads and writes, migration-related writes, and static power [1805.02514]. The point is not merely to keep hot data in fast memory, but to ensure that migration itself does not dominate latency or endurance.

The system *memos* extends the scope from page migration between DRAM and NVM to full-hierarchy scheduling over LLC, channels, banks, and media types [1703.07725]. Its SysMon module samples PTE `access_bit` and `dirty_bit` to infer hotness, read/write dominance, reuse intervals, per-channel and per-bank utilization, and cache-bank associations. It uses `W = 8` sampling windows, weight `w = 2` on writes, and a last-`K = 8` predictor; the paper reports that in `96%` of cases this predicts the next `T = 10` intervals correctly [1703.07725]. Pages predicted as write-dominant and hot are pinned to DRAM channels, while read-dominant or cold pages are pinned to NVM channels [1703.07725]. This is a memory scheduler in the OS sense rather than a passive NUMA placement heuristic.

KLOC broadens heterogeneous memory management further by showing that kernel objects, not just application pages, are critical tiering targets [2004.04760]. It characterizes kernel objects such as inodes, dentry cache entries, journal blocks, block-I/O descriptors, and network socket buffers by liveness interval, hotness, and reuse distance. Average lifetimes measured on RocksDB and Redis were `100–200 ms` for page-cache pages and `30–80 ms` for slab pages such as `sk_buff` and dentry nodes [2004.04760]. Because these intervals are short, page-table scans or multisecond sampling windows are too coarse. KLOC therefore allocates all new objects in fast memory for active contexts and demotes pages of inactive contexts in batches using Linux page migration APIs [2004.04760]. This elevates kernel-internal data structures to first-class managed memory objects within the Memory OS.

A related but more radical redesign appears in Application Read-Only Memory (AROM), which shifts LtRAM management from the DIMM controller into the OS [2606.26138]. AROM enforces the invariant that LtRAM pages are read-only to applications and written only by the OS during page migrations. Application writes to LtRAM trigger copy-on-write faults that migrate the page back to DRAM before the store is applied [2606.26138]. The one-time cost is
\[
T_{\mathrm{migrate}} = T_{\mathrm{read}}^{\mathrm{LtRAM}} + T_{\mathrm{write}}^{\mathrm{DRAM}},
\]
while wear leveling is handled through an OS token allocator with rate
\[
r = \frac{N \cdot E}{T_{\mathrm{lifetime}}},
\]
where \(N\) is the number of pages, \(E\) is erase endurance, and \(T_{\mathrm{lifetime}}\) is target lifespan [2606.26138]. This is a clear instance of a Memory OS in which hardware translation logic is deliberately simplified and responsibility is reassigned to kernel policy.

## 4. Allocation, virtualization, and protection mechanisms

A Memory Operating System may also be defined by how it restructures the boundary between kernel and process with respect to allocation and translation. The proposal for user-mode memory page allocation argued for eliminating paged virtual memory for anonymous mappings and partially outsourcing page allocation and manipulation into user space [1105.1811]. In this design, a process requests, frees, and remaps physical frames in bulk and writes directly into its own page tables under kernel validation. The intended result is `O(1)` alloc/free up to a threshold of approximately `1 MB`, scale-invariant allocation latency for common cases, and instant in-place growth or shrink through remapping rather than copying [1105.1811]. This suggests a Memory OS architecture in which page-table manipulation itself becomes part of application-visible memory control.

Another architectural line seeks finer granularity than conventional 4 KB page management. The thesis on simple DRAM and virtual-memory abstractions proposed page overlays, RowClone, Buddy RAM, Gather-Scatter DRAM, and the Dirty-Block Index as complementary mechanisms for sub-page tracking, in-DRAM bulk operations, strided access support, and dirty-state management [1605.06483]. Page overlays extend the virtual-memory framework by allowing each 4 KB virtual page to track a new version of a subset of 64 B cache lines via an Overlay Bit Vector in the TLB [1605.06483]. This directly targets inefficiency from page-granularity operations when only a small sub-page region changes.

Bulk operation support is another important dimension. RowClone performs bulk data copy and initialization entirely inside DRAM, while Buddy RAM enables bulk bitwise operations using DRAM [1605.06483]. These mechanisms matter to a Memory OS because page zeroing, copying, initialization, and remapping are among the dominant costs in large-capacity and heterogeneous memory systems. The study of terabyte-scale NVMM explicitly identifies zeroing as a dominant contributor to allocation cost and calls for zero-fill removal from the fast path, including hardware-accelerated zeroing and coordinated memory management [2310.03370]. A plausible implication is that Memory OS design increasingly depends on joint OS–hardware interfaces for memory operations that were previously treated as simple software loops.

MProtect reinterprets memory management from the protection side. It protects the entire user space of a process using a Guardian running above the OS, with Linux modified only at stable low-level interfaces such as `set_pte()`, `set_ptes()`, `commit_updates()`, `copy_from_user()`, and `copy_to_user()` [2212.12671]. Sensitive pages are presented to the OS through an encrypted view, with capability-mediated semantic access and secure exception handling [2212.12671]. This means that an OS can still manage page tables, handle page faults, scheduling, swapping, and migration while being denied arbitrary cleartext access to user-space memory. In this sense, a Memory OS is not only an allocator or migrator but a mediator of legal memory semantics.

## 5. Quantitative results and system-level trade-offs

The hybrid DRAM–NVM dual-LRU scheme reported substantial gains on PARSEC when DRAM constituted `10%` of the working set and NVM `90%`. It reduced power consumption by up to `79%` versus DRAM-only memory and by up to `48%` versus state-of-the-art CLOCK-DWF, improved AMAT by up to `70%` versus CLOCK-DWF, reduced NVM write count by up to `75%` versus NVM-only, and by up to `93%` versus CLOCK-DWF [1805.02514]. Representative workloads included `canneal`, `dedup`, and `streamcluster` [1805.02514]. These figures underscore that migration policy quality can dominate both performance and endurance.

*memos* reported average throughput gains of `19.1%` and average QoS improvement of `23.6%` on a hybrid DRAM–NVM system, while reducing NVM-side memory latency by `3~83.3%`, energy consumption by `25.1~99%`, and improving NVM lifetime by `40X` on average [1703.07725]. Its monitoring overhead was reported as `< 8%`, and page migration cost as `3 μs per 4 KB copy`, amortized through lazy batching and DMA [1703.07725]. This demonstrates that OS-level full-hierarchy scheduling can be effective even when monitoring and migration themselves are nontrivial.

KLOC showed that kernel-object tiering leaves “considerable performance on the table” if ignored. On RocksDB, Redis, Cassandra, Spark, and Filebench, it achieved `1.4X to 4X` higher throughput compared to prior art [2004.04760]. More specifically, RocksDB improved by up to `1.4×` over migration-only and `2.2×` over Nimble; Redis improved by up to `4×` over migration-only once network contexts were included; Spark improved by `1.6×–2×` for checkpoint phases; and Filebench improved by `1.7×` statically and up to `2.5×` with readahead hints [2004.04760]. This indicates that Memory OS policies that ignore filesystem and networking objects are structurally incomplete.

The NVMM study provides the converse result: where conventional OS memory management fails. Median 4 KB allocation on Optane was `33.6 %` slower than DRAM in isolated single-thread mode, and under `96 threads` median 4 KB allocation slowed by `51×` versus DRAM, while 2 MB pages slowed by approximately `39.6×` [2310.03370]. Under full fragmentation with only `50 %` free memory, serving 2 MB allocations on `1.5 TB` Optane drove median allocation latency up by `12 495×` and 99th percentile by `11 740×` relative to the unfragmented scenario [2310.03370]. By contrast, page freeing remained largely unaffected [2310.03370]. These measurements show that a Memory OS must explicitly differentiate between operations affected by media latency and capacity and those that are not.

AROM’s argument is similarly trade-off oriented. Optane’s hidden translation layer incurs overhead from cache-line granularity mismatch, on-DIMM wear-leveling migrations, address indirection table lookups, and workload-agnostic design [2606.26138]. The OS-driven alternative projects read latencies relative to Optane that are `26–79%` faster, depending on the LtRAM technology, while using page-granularity writes and OS-scheduled erases [2606.26138]. Here the trade-off is between hardware complexity and OS responsibility.

The following table summarizes several representative quantitative claims.

| System | Reported benefit | Scope |
|---|---:|---|
| Dual-LRU hybrid DRAM–NVM [1805.02514] | up to `79%` power reduction vs. DRAM-only | PARSEC, DRAM=`10%` working set |
| *memos* [1703.07725] | `19.1%` average throughput gain | full hierarchy: cache, channel, DRAM, NVM |
| KLOC [2004.04760] | `1.4X to 4X` higher throughput | kernel objects in tiered memory |
| NVMM allocator analysis [2310.03370] | `51×` median slowdown for 4 KB allocation under `96 threads` | Linux buddy allocator on Optane |
| AROM [2606.26138] | `26–79%` faster reads relative to Optane | OS-managed LtRAM interface |

These results do not define a single best design. Instead, they show that the success of a Memory OS depends on which memory objects are visible to policy, how migration and zeroing are managed, and where the hardware–software boundary is drawn.

## 6. Memory Operating Systems for AI agents

In LLM systems, the phrase “Memory Operating System” has been used to denote a control plane that manages heterogeneous machine memory representations with explicit lifecycle, scheduling, and governance. MemoryOS defines three storage tiers: short-term memory as a queue of dialogue pages, mid-term memory as segments of related pages, and long-term personal memory as persistent user and agent persona stores [2506.06326]. Short-term to mid-term updates follow a dialogue-chain-based FIFO principle, while mid-term to long-term updates use segmented page organization and a heat score
\[
Heat(s)=\alpha N_{\mathrm{visit}(s)}+\beta L_{\mathrm{interaction}(s)}+\gamma R_{\mathrm{recency}(s)},
\]
with
\[
R_{\mathrm{recency}(s)}=\exp\!\Bigl(-\frac{\Delta t}{\mu}\Bigr)
\]
[2506.06326]. Segments with \(Heat(s)\ge\tau\) are promoted to long-term personal memory [2506.06326].

MemOS broadens the ontology of memory types beyond conversational transcripts. It defines plaintext memory, activation memory, and parameter memory, all exposed through the MemCube abstraction
\[
\text{MemCube}=(P,M),
\]
where \(P\) is the payload and \(M\) stores identifiers, timestamps, origin, type, ACL, TTL, priority, provenance, version chain, and usage statistics [2507.03724]. It introduces policy-aware transitions such as promotion from plaintext to activation on hotness and fusion into parameter memory on sufficient semantic stability. The transition function is written as
\[
T(m)=
\begin{cases}
\text{activate}(m) & \mathrm{if}\;f(m)\ge\tau_1,\\
\text{parametrize}(m) & \mathrm{if}\;f(m)\ge\tau_2\wedge s(m)\ge\sigma,\\
\text{archive}(m) & \mathrm{if}\;f(m)\le\tau_0,
\end{cases}
\]
where \(f(m)\) is usage frequency and \(s(m)\) semantic stability [2507.03724]. This is strongly analogous to OS tiering and eviction, but over semantic objects rather than physical pages.

EverMemOS uses a different abstraction vocabulary centered on MemCells and MemScenes [2601.02163]. A MemCell is defined as
\[
c=(E,\mathcal{F},P,M),
\]
where \(E\) is an episodic narrative, \(\mathcal{F}\) is a set of atomic facts, \(P\) is a set of Foresight signals with validity intervals, and \(M\) is metadata [2601.02163]. MemScenes aggregate related MemCells and maintain a centroid embedding, LLM-generated summary, and scene-specific user profile updates [2601.02163]. Retrieval proceeds through dense and sparse scoring, Reciprocal Rank Fusion,
\[
\mathrm{RRF}(c)=\sum_{i\in\{\text{dense},\text{sparse}\}}\frac{1}{\mathrm{rank}_i(c)+k},
\]
scene selection, candidate pooling, and an LLM sufficiency checker that recursively issues follow-up queries if context is insufficient [2601.02163]. This is a memory manager whose analogues to allocation, compaction, paging, and garbage collection are made explicit by the authors.

Text2Mem contributes a formal operation layer for Memory OS backends [2509.11145]. It defines a JSON-schema-governed verb set—Encode, Retrieve, Delete, Merge, Promote, Demote, Split, Lock, Expire—validated by structural and semantic invariants and then mapped to typed operation objects and backend adapters [2509.11145]. Operations are modeled as functions over a memory state \(M\), with atomicity and lifecycle semantics. For example, deletion requires \(\neg o.\mathrm{locked}\), soft deletion maps status to `"deleted"`, and hard deletion maps \(o\mapsto\emptyset\) [2509.11145]. This suggests a maturation from heuristic memory frameworks to formally specified, executable Memory OS interfaces.

Empirically, these AI systems report benchmark gains. MemoryOS reported on LoCoMo an average improvement of `49.11%` on F1 and `46.18%` on BLEU-1 over the baselines on GPT-4o-mini [2506.06326]. EverMemOS reported `86.76%` overall accuracy on LoCoMo versus Zep’s `81.06%`, `83.00%` overall on LongMemEval versus MemOS’s `77.80%`, and `53.25%` on PersonaMem v2 versus the best baseline MemOS at `50.72%` [2601.02163]. MemOS reported on LOCOMO that MemOS-0630 outperformed baselines including LangMem, Zep, OpenAI-Memory, and Mem0, with overall LLM-Judge score approximately `73.31±0.05`, and that KV injection reduced Time-to-First-Token by `60–94 %` while preserving identical outputs [2507.03724]. These results indicate that the Memory OS abstraction is not merely metaphorical in AI systems; it is directly tied to memory representation, retrieval latency, and reasoning performance.

## 7. Limitations, debates, and future directions

One recurring debate concerns whether existing abstractions can simply be adapted or whether they must be replaced. In SCM research, the conclusion was pessimistic about preserving POSIX as-is: OS and metadata system calls are important optimization targets, but synchronization-related calls remain dominant and are not eliminated even by RAMdisk platforms [1712.07759]. This suggests that a Memory OS for persistent memory may require user-space metadata, direct load/store APIs, or library-OS designs rather than incremental POSIX tuning.

A second debate concerns where control should reside: in hardware, the kernel, user space, or an external monitor. AROM explicitly moves wear leveling and write-granularity management from the DIMM controller to the OS [2606.26138]. User-mode page allocation moves some page management from the kernel to the process [1105.1811]. MProtect moves sensitive mediation above the OS into the Guardian [2212.12671]. These designs are not interchangeable; they embody different trust models, overhead structures, and implementation constraints.

A third debate concerns how broad the unit of management should be. Many early systems manage pages, but KLOC argues that kernel objects must also be first-class citizens [2004.04760]. MemOS and EverMemOS go further still, treating semantically structured objects with provenance, summaries, and version chains as memory units [2507.03724], [2601.02163]. This suggests a general trend from fixed-size blocks toward richer memory objects whose identity is defined by semantics and lifecycle rather than address alone.

Several limitations recur across the literature. In hardware-tiered systems, excessive migration burns NVM write cycles, blind promotion can dominate AMAT, and large-scale compaction becomes prohibitive on NVMM [1805.02514], [2310.03370]. In protection-oriented systems, mediation on every context switch, page fault, and syscall introduces `~2–5 μs` per-event overhead, and software cryptography dominates cold-start costs [2212.12671]. In AI-oriented Memory OS frameworks, multiple LLM calls for segmentation, consolidation, and sufficiency checking add latency and cost, while benchmark coverage remains incomplete for profile stability and foresight [2601.02163]. Text2Mem itself outlines Text2Mem Bench as a planned benchmark, indicating that standardized evaluation remains an open problem [2509.11145].

Future directions follow naturally from these tensions. The NVMM literature calls for zeroing elimination, latency-aware allocators, persistence-aware page-table placement, fragmentation avoidance, and coordinated memory-management subsystems [2310.03370]. The Memory OS literature for AI systems points toward cross-platform memory portability, memory interchange protocols, decentralized memory marketplaces, self-optimizing memory units, multimodal extension, and formalized operation languages [2507.03724], [2505.22101], [2509.11145]. A plausible implication is that the term “Memory Operating System” will continue to converge around a common pattern: memory represented as typed objects with lifecycle state, explicit governance, migration policies, and programmable operations, whether the substrate is DRAM/NVMM hardware or the heterogeneous internal and external memory of an AI agent.

Source: https://www.emergentmind.com/topics/memory-operating-system