kmalloc

Posted Apr 11, 2025 6:37 UTC (Fri) by gmprice (subscriber, #167884)
In reply to: kmalloc by willy
Parent article: Management of volatile CXL devices

Framing the discussion as "why would i deliberately use slower memory" is quite disingenuous considering zswap, zram, and swap all exist.

The answer is pretty clearly - to avoid having to use all of those things.

There is maybe a good argument to formalize a zswap backend allocator that can consume dax-memory, and hide that from the page allocator - but there is still clear value in just exposing it as a page. It's literally DDR behind a controller, not some pseudo-nand or page-fetch interconnect.

kmalloc

Posted Apr 11, 2025 18:29 UTC (Fri) by willy (subscriber, #9762) [Link]

> It's literally DDR behind a controller, not some pseudo-nand or page-fetch interconnect.

That's actually worse than the 3dxp business case. Because in the future where 3dxp had worked, the argument was that it came in VAST quantities. If I remember correctly, the argument at the time was for a 2 socket machine with 128GB of DRAM, 8TB of 3dxp and some amount of NVMe storage.

So you might reasonably want to say "Hey, give me 4TB of slow memory" because you'd designed your algorithm to be tolerant of that latency.

And then 3dxp also had the persistence argument for it; maybe there really was a use-case for storage-presented-as-memory. Again, CXL as envisaged by you doesn't provide that either. It's just DRAM behind a slow interconnect.