by Dan Williams

[permalink] [raw]

Subject: Re: [PATCH RFC 0/7] block: Introduce CBD (CXL Block Device)

Dongsheng Yang wrote:
>
>
> 在 2024/4/25 星期四上午 2:08, Dan Williams 写道:
> > Dongsheng Yang wrote:
> >>
> >>
> >> 在 2024/4/24 星期三下午 12:29, Dan Williams 写道:
> >>> Dongsheng Yang wrote:
> >>>> From: Dongsheng Yang <[email protected]>
> >>>>
> >>>> Hi all,
> >>>> This patchset introduce cbd (CXL block device). It's based on linux 6.8, and available at:
> >>>> https://github.com/DataTravelGuide/linux
> >>>>
> >>> [..]
> >>>> (4) dax is not supported yet:
> >>>> same with famfs, dax device is not supported here, because dax device does not support
> >>>> dev_dax_iomap so far. Once dev_dax_iomap is supported, CBD can easily support DAX mode.
> >>>
> >>> I am glad that famfs is mentioned here, it demonstrates you know about
> >>> it. However, unfortunately this cover letter does not offer any analysis
> >>> of *why* the Linux project should consider this additional approach to
> >>> the inter-host shared-memory enabling problem.
> >>>
> >>> To be clear I am neutral at best on some of the initiatives around CXL
> >>> memory sharing vs pooling, but famfs at least jettisons block-devices
> >>> and gets closer to a purpose-built memory semantic.
> >>>
> >>> So my primary question is why would Linux need both famfs and cbd? I am
> >>> sure famfs would love feedback and help vs developing competing efforts.
> >>
> >> Hi,
> >> Thanks for your reply, IIUC about FAMfs, the data in famfs is stored in
> >> shared memory, and related nodes can share the data inside this file
> >> system; whereas cbd does not store data in shared memory, it uses shared
> >> memory as a channel for data transmission, and the actual data is stored
> >> in the backend block device of remote nodes. In cbd, shared memory works
> >> more like network to connect different hosts.
> >>
> >> That is to say, in my view, FAMfs and cbd do not conflict at all; they
> >> meet different scenario requirements. cbd simply uses shared memory to
> >> transmit data, shared memory plays the role of a data transmission
> >> channel, while in FAMfs, shared memory serves as a data store role.
> >
> > If shared memory is just a communication transport then a block-device
> > abstraction does not seem a proper fit. From the above description this
> > sounds similar to what CONFIG_NTB_TRANSPORT offers which is a way for
> > two hosts to communicate over a shared memory channel.
> >
> > So, I am not really looking for an analysis of famfs vs CBD I am looking
> > for CBD to clarify why Linux should consider it, and why the
> > architecture is fit for purpose.
>
> Let me explain why we need cbd:
>
> In cloud storage scenarios, we often need to expose block devices of
> storage nodes to compute nodes. We have options like nbd, iscsi, nvmeof,
> etc., but these all communicate over the network. cbd aims to address
> the same scenario but using shared memory for data transfer instead of
> the network, aiming for better performance and reduced network latency.
>
> Furthermore, shared memory can not only transfer data but also implement
> features like write-ahead logging (WAL) or read/write cache, further
> improving performance, especially latency-sensitive business scenarios.
> (If I understand correctly, this might not be achievable with the
> previously mentioned ntb.)
>
> To ensure we have a common understanding, I'd like to clarify one point:
> the /dev/cbdX block device is not an abstraction of shared memory; it is
> a mapping of a block device (such as /dev/sda) on the remote host.
> Reading/writing to /dev/cbdX is equivalent to reading/writing to
> /dev/sda on the remote host.
>
> This is the design intention of cbd. I hope this clarifies things.

I does, thanks for the clarification. Let me go back and take a another
look now that I undertand that this is a "remote storage target over CXL
memory" solution.

2024-04-30 00:34:54

by Dan Williams

[permalink] [raw]

Subject: Re: [PATCH RFC 0/7] block: Introduce CBD (CXL Block Device)

Dongsheng Yang wrote:
>
>
> 在 2024/4/27 星期六上午 12:14, Gregory Price 写道:
> > On Fri, Apr 26, 2024 at 10:53:43PM +0800, Dongsheng Yang wrote:
> >>
> >>
> >> 在 2024/4/26 星期五下午 9:48, Gregory Price 写道:
> >>>
> >>
> >> In (5) of the cover letter, I mentioned that cbd addresses cache coherence
> >> at the software level:
> >>
> >> (5) How do blkdev and backend interact through the channel?
> >> a) For reader side, before reading the data, if the data in this channel
> >> may be modified by the other party, then I need to flush the cache before
> >> reading to ensure that I get the latest data. For example, the blkdev needs
> >> to flush the cache before obtaining compr_head because compr_head will be
> >> updated by the backend handler.
> >> b) For writter side, if the written information will be read by others,
> >> then after writing, I need to flush the cache to let the other party see it
> >> immediately. For example, after blkdev submits cbd_se, it needs to update
> >> cmd_head to let the handler have a new cbd_se. Therefore, after updating
> >> cmd_head, I need to flush the cache to let the backend see it.
> >>
> >
> > Flushing the cache is insufficient. All that cache flushing guarantees
> > is that the memory has left the writer's CPU cache. There are potentially
> > many write buffers between the CPU and the actual backing media that the
> > CPU has no visibility of and cannot pierce through to force a full
> > guaranteed flush back to the media.
> >
> > for example:
> >
> > memcpy(some_cacheline, data, 64);
> > mfence();
> >
> > Will not guarantee that after mfence() completes that the remote host
> > will have visibility of the data. mfence() does not guarantee a full
> > flush back down to the device, it only guarantees it has been pushed out
> > of the CPU's cache.
> >
> > similarly:
> >
> > memcpy(some_cacheline, data, 64);
> > mfence();
> > memcpy(some_other_cacheline, data, 64);
> > mfence()
> >
> > Will not guarantee that some_cacheline reaches the backing media prior
> > to some_other_cacheline, as there is no guarantee of write-ordering in
> > CXL controllers (with the exception of writes to the same cacheline).
> >
> > So this statement:
> >
> >> I need to flush the cache to let the other party see it immediately.
> >
> > Is misleading. They will not see is "immediately", they will see it
> > "eventually at some completely unknowable time in the future".
>
> This is indeed one of the issues I wanted to discuss at the RFC stage.
> Thank you for pointing it out.
>
> In my opinion, using "nvdimm_flush" might be one way to address this
> issue, but it seems to flush the entire nd_region, which might be too
> heavy. Moreover, it only applies to non-volatile memory.
>
> This should be a general problem for cxl shared memory. In theory, FAMFS
> should also encounter this issue.
>
> Gregory, John, and Dan, Any suggestion about it?

The CXL equivalent is GPF (Global Persistence Flush), not be confused
with "General Protection Fault" which is likely what will happen if
software needs to manage cache coherency for this solution. CXL GPF was
not designed to be triggered by software. It is hardware response to a
power supply indicating loss of input power.

I do not think you want to spend community resources reviewing software
cache coherency considerations, and instead "just" mandate that this
solution requires inter-host hardware cache coherence. I understand that
is a difficult requirement to mandate, but it is likely less difficult
than getting Linux to carry a software cache coherence mitigation.

In some ways this reminds me of SMR drives and the problems those posed
to software where ultimately the programming difficulties needed to be
solved in hardware, not exported to the Linux kernel to solve.