Re: [RFC] Memory tiering kernel alignment

[David Hildenbrand <david@redhat.com>]

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