Source linked

AROM Flips the OS-DIMM Contract to Fix LtRAM's Slow Writes

Instead of hiding LtRAM's asymmetric write latency behind a hardware translation layer like Intel Optane, AROM makes application memory read-only and lets the OS handle writes via copy-on-write page migrations.

ltramintel optaneoperating systemsmemory architecturecopy on writeapplication read only memory

DRAM's cost-per-bit hasn't budged in a decade, and emerging LtRAM technologies like Intel Optane try to paper over their terrible write latency with on-DIMM controllers that just add more overhead.

Why Hardware Translation Layers Fail LtRAM

LtRAM (Long-term RAM) promises denser, cheaper main memory, but it comes with three hard knocks: asymmetric read/write latencies, limited endurance, and coarse write granularity. Intel Optane copies the flash playbook, sticking a translation layer on the DIMM to handle wear-leveling, address remapping, and read/write caching. Prior experimental studies show these operations add significantly to latency. You're paying for density and getting DRAM-like pain with extra complexity.

AROM: The OS Takes the Write Wheel

The authors propose redesigning the hardware/software interface instead. The central property: Application Read-Only Memory (AROM). LtRAM pages are read-only to applications. Only the OS writes to LtRAM, and only during page migrations. Every application store to an LtRAM page triggers a page fault that copies the page back to DRAM before the store executes. That's classic copy-on-write (CoW), but applied at the memory tier level.

This flips the management model. The on-DIMM controller goes from a complex, latency-hiding beast to a simple dumb device. All wear-leveling, address remapping, and caching moves to the OS, where it can exploit page-level knowledge and software flexibility.

The Read-Mostly Bet

AROM is not for every workload. If your application writes constantly to LtRAM pages, you'll pay the CoW migration penalty every time. But read-mostly workloads -- think database caches, ML model weights, read-heavy VMs -- can keep hot pages in DRAM and cold read-only data on cheaper LtRAM. The goal: match pure DRAM performance on those workloads while delivering LtRAM's density and cost advantages.

No benchmark numbers yet; this is a systems design proposal. But the idea is clean: stop pretending LtRAM is DRAM, and let the OS own the asymmetry. Expect follow-up papers with real cycle-level evaluations on Optane-like hardware or emulated LtRAM DIMMs.


Source: The Kernel's Write: Application Read-Only Memory
Domain: arxiv.org

Read original source ->

External source stays available while the OJO article and comment thread stay local.

Comments load interactively on the live page.