Re: [RFC] Memory tiering kernel alignment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 25.01.24 21:19, Matthew Wilcox wrote:
On Thu, Jan 25, 2024 at 12:04:37PM -0800, David Rientjes wrote:
On Thu, 25 Jan 2024, Matthew Wilcox wrote:
On Thu, Jan 25, 2024 at 10:26:19AM -0800, David Rientjes wrote:
There is a lot of excitement around upcoming CXL type 3 memory expansion
devices and their cost savings potential.  As the industry starts to
adopt this technology, one of the key components in strategic planning is
how the upstream Linux kernel will support various tiered configurations
to meet various user needs.  I think it goes without saying that this is
quite interesting to cloud providers as well as other hyperscalers :)

I'm not excited.  I'm disappointed that people are falling for this scam.
CXL is the ATM of this decade.  The protocol is not fit for the purpose
of accessing remote memory, adding 10ns just for an encode/decode cycle.
Hands up everybody who's excited about memory latency increasing by 17%.

Right, I don't think that anybody is claiming that we can leverage locally
attached CXL memory as through it was DRAM on the same or remote socket
and that there won't be a noticable impact to application performance
while the memory is still across the device.

It does offer several cost savings benefits for offloading of cold memory,
though, if locally attached and I think the support for that use case is
inevitable -- in fact, Linux has some sophisticated support for the
locally attached use case already.

Then there are the lies from the vendors who want you to buy switches.
Not one of them are willing to guarantee you the worst case latency
through their switches.

I should have prefaced this thread by saying "locally attached CXL memory
expansion", because that's the primary focus of many of the folks on this
email thread :)

That's a huge relief.  I was not looking forward to the patches to add
support for pooling (etc).

The issue is that CXL standard is at this point extremely over-engineered with obscure use cases, and features that feel completely detached from reality -- especially, what a commodity OS can support and would be willing to support.

Thanks for expressing what I've been thinking all of the time. CXL is IMHO great for cheap (slow/cold) memory, GPGPUs etc, and I'm hoping that will be the primary focus for the near future -- not all of that dynamic capacity, memory pooling etc crap (sorry).

--
Cheers,

David / dhildenb





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux