Speaker
Description
When multiple kernels or CXL-connected hosts share byte-addressable memory, every existing filesystem option pays a copy per participant: tmpfs replicates content N times, erofs and fscache keep a private page cache per kernel. To ground the discussion we bring DAXFS, a prototype filesystem that runs directly on DAX memory with no block layer: one shared namespace, a cooperative page cache in the shared region, and mounts backed by a raw physical range or a dma-buf, so GPUs reach file data zero-copy through the backing buffer. Unlike famfs, where a userspace master preallocates files and distributes metadata to read-only clients out of band, DAXFS is masterless: metadata lives in the shared region itself and any participant can create files and COW-write pages concurrently through lock-free CAS updates, no metadata server, no out-of-band log.
The killer use case we are building toward is checkpoint and restore of AI agent sandboxes. Thousands of short-lived agent instances share one mapping of the base rootfs and model weights, with writable state as COW overlay pages in shared memory. Today the image carries a single shared overlay; giving each sandbox its own sealable overlay would make checkpoint a seal operation and restore (or forking N agents from one checkpoint) just a map: no gigabytes serialized through a block device, cold start drops from minutes to seconds.
Building it surfaced gaps bigger than one filesystem, and we want the MC to weigh in:
-
DAXFS bypasses fs/dax entirely (memremap plus raw PFN mappings) because fs/dax assumes a filesystem privately owns its dax_device. How do shared multi-writer DAX mappings become supported, not a special case?
-
Is a filesystem the right ABI for pooled memory carved into named shareable objects, or should this be device-dax, a sparse memfd (per the DCD discussions), or guest_memfd-shaped?
-
DAXFS mounts from an imported dma-buf today; exporting per-file extents as dma-bufs is the natural next step. What are the lifetime and coherence rules when the exporter is a filesystem over shared device memory, with P2P DMA targeting it?
-
Who owns allocation when N hosts share a Dynamic Capacity Device, and how does DCD extent release interact with live filesystem data?
-
Where is the line between memory core MM manages and memory a cross-kernel service manages, and how do hotness tracking and migration see pages no single kernel owns?