Received-SPF: pass (google.com: domain of linux-kernel+bounces-198540-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Subject: Re: [PATCH RFC 0/7] block: Introduce CBD (CXL Block Device)
To: Gregory Price <gregory.price@memverge.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
 Jonathan Cameron <Jonathan.Cameron@huawei.com>, John Groves
 <John@groves.net>, axboe@kernel.dk, linux-block@vger.kernel.org,
 linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org,
 nvdimm@lists.linux.dev
References: <20240508131125.00003d2b@Huawei.com>
 <ef0ee621-a2d2-e59a-f601-e072e8790f06@easystack.cn>
 <20240508164417.00006c69@Huawei.com>
 <3d547577-e8f2-8765-0f63-07d1700fcefc@easystack.cn>
 <20240509132134.00000ae9@Huawei.com>
 <a571be12-2fd3-e0ee-a914-0a6e2c46bdbc@easystack.cn>
 <664cead8eb0b6_add32947d@dwillia2-mobl3.amr.corp.intel.com.notmuch>
 <8f161b2d-eacd-ad35-8959-0f44c8d132b3@easystack.cn>
 <ZldIzp0ncsRX5BZE@memverge.com>
 <5db870de-ecb3-f127-f31c-b59443b4fbb4@easystack.cn>
 <Zlndc8NI0eK3MmuR@memverge.com>
From: Dongsheng Yang <dongsheng.yang@easystack.cn>
Message-ID: <a04a5bbc-a44b-57e4-0fa6-0ce84b18a395@easystack.cn>
Date: Mon, 3 Jun 2024 09:33:29 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.4.0
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <Zlndc8NI0eK3MmuR@memverge.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit


在 2024/5/31 星期五 下午 10:23, Gregory Price 写道:
> On Thu, May 30, 2024 at 02:59:38PM +0800, Dongsheng Yang wrote:
>>
>>
>> 在 2024/5/29 星期三 下午 11:25, Gregory Price 写道:
>>>
>>> There are some (FAMFS, for example). The coherence state of these
>>> systems tend to be less volatile (e.g. mappings are read-only), or
>>> they have inherent design limitations (cacheline-sized message passing
>>> via write-ahead logging only).
>>
>> Can you explain more about this? I understand that if the reader in the
>> writer-reader model is using a readonly mapping, the interaction will be
>> much simpler. However, after the writer writes data, if we don't have a
>> mechanism to flush and invalidate puncturing all caches, how can the
>> readonly reader access the new data?
> 
> This is exactly right, so the coherence/correctness of the data needs to
> be enforced in some other way.
> 
> Generally speaking, the WPQs will *eventually* get flushed.  As such,
> the memory will *eventually* become coherent.  So if you set up the
> following pattern, you will end up with an "eventually coherent" system


Yes, it is "eventually coherent" if "NO CLEAN WRITEBACK" bit in both 
CSDS and DVSEC is set.
> 
> 1) Writer instantiates the memory to be used
> 2) Writer calculates and records a checksum of that data into memory
> 3) Writer invalidates everything
> 4) Reader maps the memory
> 5) Reader reads the checksum and calculates the checksum of the data
>     a) if the checksums match, the data is coherent
>     b) if they don't, we must wait longer for the queues to flush

Yes, the checksum was mentioned by John, it is used in FAMFS/pcq_lib.c, 
pcq use sequence and checksum in consumer to make sure data consistency.

I think it's a good idea and was planning to introduce it into cbd, of 
coures it should be optional for cbd, as cbd current only supports
hardware-consistency usage. it can be an option to do data verification.

Thanx
> 
> This is just one example of a system design which enforces coherence by
> placing the limitation on the system that the data will never change
> once it becomes coherent.
> 
> Whatever the case, regardless of the scheme you come up with, you will
> end up with a system where the data must be inspected and validated
> before it can be used.  This has the limiting factor of performance:
> throughput will be limited by how fast you can validate the data.
> 
> ~Gregory
> .
>