Shared CXL 3 memory what will be required
summary
Argues that CXL 3 sharable tagged capacity must never be onlined as system RAM and instead needs a more file-like layer so existing apps can mmap datasets without devdax changes. Presents a working famfs prototype built on ramfs+hugetlbfs+xfs that preallocates extents, sets S_DAX on files, and uses a log‑structured master/clients with preallocated files and user‑space log play; it currently exposes metadata-per-client, works for zero‑copy Apache Arrow style workloads, and still needs fixes for iomap, coherency and error handling.
AI-written summary · about
chapters (14)
- 0:00Introduction to CXL 3 shared memory
- 1:06Need for shared scale-out fsdax
- 3:14Why raw DAX isn't enough
- 4:59FSDAX and VFS layer potential
- 7:26Data science toolchain leverage
- 9:13Use cases for fabric-attached memory
- 10:19Why DAX alone won't suffice
- 12:05Requirements for shared FSDAX
- 13:07Current prototype architecture
- 16:44File creation and log play
- 17:26PIM vs DAX challenges
- 18:53Goals and future plans
- 20:38Error handling considerations
- 22:25Q&A and discussion
related talks
43mExpanding the Memory Limits with CXL Software Stack
30mCXL Dynamic Capacity MM
31mDesign and implementation of Autocaching for CXLSSD
24mxadfs: Inverted DAX
03mCXL MC Welcome and Kickoff
39mCompute Express Link(CXL), the Next Generation Interconnect - Overview and the Status of Linux
22mPreserving guest memory across kexec
37mMeta’s CXL Journey and Learnings in Linux