Message-ID: <aa71c034-abf1-4861-8440-e327e535ed7e@linux.alibaba.com>
Date: Fri, 23 Jan 2026 13:58:11 +0800
From: Gao Xiang <hsiangkao@...ux.alibaba.com>
To: Christoph Hellwig <hch@....de>
Cc: Hongbo Li <lihongbo22@...wei.com>, chao@...nel.org, djwong@...nel.org,
 amir73il@...il.com, linux-fsdevel@...r.kernel.org,
 linux-erofs@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 Christian Brauner <brauner@...nel.org>, oliver.yang@...ux.alibaba.com
Subject: Re: [PATCH v15 5/9] erofs: introduce the page cache share feature



On 2026/1/23 13:39, Christoph Hellwig wrote:
> On Thu, Jan 22, 2026 at 04:40:56PM +0800, Gao Xiang wrote:
>>> Having multiple folios for the same piece of memory can't work,
>>> at we'd have unsynchronized state.
>>
>> Why not just left unsynchronized state in a unique way,
>> but just left mapping + indexing seperated.
> 
> That would not just require allocating the folios dynamically, but most
> importantly splitting it up.  We'd then also need to find a way to chain
> the folio_link structures from the main folio.  I'm not going to see this
> might not happen, but it feels very far out there and might have all
> kinds of issues.

I can see the way, but at least I don't have any resource,
and I'm even not sure it will happen in the foresee future,
so that is why we will not wait for per-folio sharing
anymore (memory is already becoming $$$$$$..).

> 
>>>>> I think the concept of using a backing file of some sort for the shared
>>>>> pagecache (which I have no problem with at all), vs the imprecise
>>>>
>>>> In that way (actually Jingbo worked that approach in 2023),
>>>> we have to keep the shared data physically contiguous and
>>>> even uncompressed, which cannot work for most cases.
>>>
>>> Why does that matter?
>>
>> Sorry then, I think I don't get the point, but we really
>> need this for the complete page cache sharing on the
>> single physical machine.
> 
> Why do you need physically contigous space to share it that way?

Yes, it won't be necessary, but the main goal is to share
various different filesystem images with consensus per-inode
content-addressable IDs, either secure hashs or per-inode UUIDs.

I still think it's very useful considering finer-grain page
cache sharing can only exist in our heads so I will go on use
this way for everyone to save memory (considering AI needs
too much memory and memory becomes more expensive.)

> 
>>>
>>>> On the other side, I do think `fingerprint` from design
>>>> is much like persistent NFS file handles in some aspect
>>>> (but I don't want to equal to that concept, but very
>>>> similar) for a single trusted domain, we should have to
>>>> deal with multiple filesystem sources and mark in a
>>>> unique way in a domain.
>>>
>>> I don't really thing they are similar in any way.
>>
>> Why they are not similiar, you still need persistent IDs
>> in inodes for multiple fses, if there are a
>> content-addressable immutable filesystems working in
>> inodes, they could just use inode hashs as file handles
>> instead of inode numbers + generations.
> 
> Sure, if they are well defined, cryptographically secure hashes.  But

EROFS is a golden image filesystem generated purely in
userspace, vendors will use secure hashs or
per-vendor-generated per-inode UUID.

> that's different from file handles, which don't address content at all,
> but are just a handle to given file that bypasses the path lookup.

I agree, so I once said _somewhat_ similar.  Considering
content-addressable filesystems, of course they could use
simplifed secure hashs as file handles in some form.

Thanks,
Gao Xiang

> 
>>
>> Thanks,
>> Gao Xiang
> ---end quoted text---

Powered by blists - more mailing lists