RE: Re: RE: FW: [LSF/MM/BPF TOPIC] SMDK inspired MM changes for CXL

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

 



>On Fri, Mar 31, 2023 at 08:42:20PM +0900, Kyungsan Kim wrote:
>> Given our experiences/design and industry's viewpoints/inquiries,
>> I will prepare a few slides in the session to explain 
>>   1. Usecase - user/kernespace memory tiering for near/far placement, memory virtualization between hypervisor/baremetal OS
>>   2. Issue - movability(movable/unmovable), allocation(explicit/implicit), migration(intented/unintended)
>>   3. HW - topology(direct, switch, fabric), feature(pluggability,error-handling,etc)
>
>I think you'll find everybody else in the room understands these issues
>rather better than you do.  This is hardly the first time that we've
>talked about CXL, and CXL is not the first time that people have
>proposed disaggregated memory, nor heterogenous latency/bandwidth
>systems.  All the previous attempts have failed, and I expect this
>one to fail too.  Maybe there's something novel that means this time
>it really will work, so any slides you do should focus on that.
>
>A more profitable discussion might be:
>
>1. Should we have the page allocator return pages from CXL or should
>   CXL memory be allocated another way?
I think yes. Using CXL DRAM as System RAM interface would be the primary use case in real-world application in regards to compatibility.
So, on the System RAM interface, we think it should be managed by Linux MM subsystem. (Node - Zonelist - buddy page allocator)

>2. Should there be a way for userspace to indicate that it prefers CXL
>   memory when it calls mmap(), or should it always be at the discretion
>   of the kernel?
I think yes. Both implcit and explict ways are meaningful for users on a different purpose.
The dynamic performance variation of CXL DRAM is likely bigger than other memory types due to the topology expansion and link negotiation.
I think it strengthens the needs.


>3. Do we continue with the current ZONE_DEVICE model, or do we come up
>   with something new?
In fact, ZONE_DEVICE was the our first candidate for CXL DRAM.
But because ZONE_DEVICE is not managed by buddy, we thought it does not fit to provide System RAM interface.





[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