It is true that disaggregated memory is more prone to failures, due to more complex connections. And if you online disaggregated memory as system-ram, that puts the kernel at risk to some extent. One mitigation is putting the memory in ZONE_MOVABLE, which discourages (prevents?) kernel allocations from using it. I think that is the normal path now (?).

But another usage pattern is near to my heart: raw dax and/or famfs (the Fabric-Attached Memory File System). If apps use raw dax, the kernel doesn't use the memory - so the memory failure blast radius will normally be limited to the app(s) that use it. Using raw dax in apps requires modifications and/or awareness, but there are apps that already have that capability (e.g. qemu and lmcache).

If the dax devices are formatted as famfs, the same is true. Dax notifies famfs of memory failures, and currently we just do an "emergency" unmount. That means apps that are using famfs files will most likely crash, but again it should not crash the kernel.

Famfs turns collections of dax devices (presumably, but not necessarily, shared) into a scale-out file system. Many usage patterns require no app modifications to use famfs, although some of those do require work flow modifications. Famfs adds memory-interleaved files, posix permissions, and strict isolation between files on top of the dax abstraction.

John
(I'm the famfs guy, and also co-chair of the CXL software and systems working group)