Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sat, 22 Jan 2022 16:09:13 +0000
From:   Matthew Wilcox <willy@infradead.org>
To:     Thomas Schoebel-Theuer <tst@schoebel-theuer.de>
Cc:     "Longpeng (Mike, Cloud Infrastructure Service Product Dept.)" 
        <longpeng2@huawei.com>, Khalid Aziz <khalid.aziz@oracle.com>,
        Barry Song <21cnbao@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Arnd Bergmann <arnd@arndb.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        David Hildenbrand <david@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Linux-MM <linux-mm@kvack.org>, Mike Rapoport <rppt@kernel.org>,
        Suren Baghdasaryan <surenb@google.com>
Subject: Re: [RFC PATCH 0/6] Add support for shared PTEs across processes
Message-ID: <YewsKfCUb6tI5jHs@casper.infradead.org>
References: <cover.1642526745.git.khalid.aziz@oracle.com>
 <20220121010806.5607-1-21cnbao@gmail.com>
 <YeoW4CMiU8qbRFST@casper.infradead.org>
 <CAGsJ_4wv144TUSQPNOnHnmNmJrXe4Fn8d14JeAJ5ka-S+dRxRA@mail.gmail.com>
 <YerHceldiYXLk2DE@casper.infradead.org>
 <0ec88ae7-9740-835d-1f07-60bd57081fcd@oracle.com>
 <b34ded1e11154eabbce07618bf0a6676@huawei.com>
 <Yetgy/eT+rZBgSq7@casper.infradead.org>
 <cb55951f-3c30-61e3-23a3-7a99064918b7@schoebel-theuer.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cb55951f-3c30-61e3-23a3-7a99064918b7@schoebel-theuer.de>
Precedence: bulk

On Sat, Jan 22, 2022 at 11:18:14AM +0100, Thomas Schoebel-Theuer wrote:
> On 1/22/22 2:41 AM, Matthew Wilcox wrote:
> > On Sat, Jan 22, 2022 at 01:39:46AM +0000, Longpeng (Mike, Cloud Infrastructure Service Product Dept.) wrote:
> > > > > Our use case is that we have some very large files stored on persistent
> > > > > memory which we want to mmap in thousands of processes.  So the first
> > > The memory overhead of PTEs would be significantly saved if we use
> > > hugetlbfs in this case, but why not?
> > Because we want the files to be persistent across reboots.
> 
> 100% agree. There is another use case: geo-redundancy.
> 
> My view is publicly documented at
> https://github.com/schoebel/mars/tree/master/docu and click at
> architecture-guide-geo-redundancy.pdf

That's a 160+ page PDF.  No offence, Thomas, I'm not reading that to
try to understand how you want to use page table sharing.

> In some scenarios, migration or (temporary) co-existence of block devices
> from/between hardware architecture A to/between hardware architecture B
> might become a future requirement for me.

I'm not sure how sharing block devices between systems matches up with
sharing page tables between processes.

> It would be great if msharefs is not only low-footprint, but also would be
> usable from kernelspace.

I don't understand what you want here either.  Kernel threads already
share their page tables.