Re: [RFC PATCH 00/11] pcache: Persistent Memory Cache for Block Devices

[Dongsheng Yang]

+ccing md-devel

On 2025/4/16 23:10, Jens Axboe wrote:
> On 4/16/25 12:08 AM, Dongsheng Yang wrote:
> > On 2025/4/16 9:04, Jens Axboe wrote:
> > > On 4/15/25 12:00 PM, Dan Williams wrote:
> > > > Thanks for making the comparison chart. The immediate question this
> > > > raises is why not add "multi-tree per backend", "log structured
> > > > writeback", "readcache", and "CRC" support to dm-writecache?
> > > > device-mapper is everywhere, has a long track record, and enhancing it
> > > > immediately engages a community of folks in this space.
> > > Strongly agree.
> >
> > Hi Dan and Jens,
> > Thanks for your reply, that's a good question.
> >
> >      1. Why not optimize within dm-writecache?
> >  From my perspective, the design goal of dm-writecache is to be a
> > minimal write cache. It achieves caching by dividing the cache device
> > into n blocks, each managed by a wc_entry, using a very simple
> > management mechanism. On top of this design, it's quite difficult to
> > implement features like multi-tree structures, CRC, or log-structured
> > writeback. Moreover, adding such optimizations?especially a read
> > cache?would deviate from the original semantics of dm-writecache. So,
> > we didn't consider optimizing dm-writecache to meet our goals.
> >
> >      2. Why not optimize within bcache or dm-cache?
> > As mentioned above, dm-writecache is essentially a minimal write
> > cache. So, why not build on bcache or dm-cache, which are more
> > complete caching systems? The truth is, it's also quite difficult.
> > These systems were designed with traditional SSDs/NVMe in mind, and
> > many of their design assumptions no longer hold true in the context of
> > PMEM. Every design targets a specific scenario, which is why, even
> > with dm-cache available, dm-writecache emerged to support DAX-capable
> > PMEM devices.
> >
> >      3. Then why not implement a full PMEM cache within the dm framework?
> > In high-performance IO scenarios?especially with PMEM hardware?adding
> > an extra DM layer in the IO stack is often unnecessary. For example,
> > DM performs a bio clone before calling __map_bio(clone) to invoke the
> > target operation, which introduces overhead.
> >
> > Thank you again for the suggestion. I absolutely agree that leveraging
> > existing frameworks would be helpful in terms of code review, and
> > merging. I, more than anyone, hope more people can help review the
> > code or join in this work. However, I believe that in the long run,
> > building a standalone pcache module is a better choice.
> I think we'd need much stronger reasons for NOT adopting some kind of dm
> approach for this, this is really the place to do it. If dm-writecache
> etc aren't a good fit, add a dm-whatevercache for it? If dm is
> unnecessarily cloning bios when it doesn't need to, then that seems like
> something that would be worthwhile fixing in the first place, or at
> least eliminate for cases that don't need it. That'd benefit everyone,
> and we would not be stuck with a new stack to manage.
>
> Would certainly be worth exploring with the dm folks.

well, introducing dm-pcache (assuming we use this name) could, on one 
hand, attract more users and developers from the device-mapper community 
to pay attention to this project, and on the other hand, serve as a way 
to validate or improve the dm framework’s performance in 
high-performance I/O scenarios. If necessary, we can enhance the dm 
framework instead of bypassing it entirely. This indeed sounds like 
something that would “benefit everyone.”

Hmm, I will seriously consider this approach.

Hi Alasdair, Mike, Mikulas,  Do you have any suggestions?

Thanx

>