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;
From:   Thomas Schoebel-Theuer <tst@schoebel-theuer.de>
Subject: Re: [RFC PATCH 0/6] Add support for shared PTEs across processes
To:     Matthew Wilcox <willy@infradead.org>,
        "Longpeng (Mike, Cloud Infrastructure Service Product Dept.)" 
        <longpeng2@huawei.com>
Cc:     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>
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>
Message-ID: <cb55951f-3c30-61e3-23a3-7a99064918b7@schoebel-theuer.de>
Date:   Sat, 22 Jan 2022 11:18:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <Yetgy/eT+rZBgSq7@casper.infradead.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk

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

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.

The currrent implementation does not yet use hugetlbfs and/or its 
proposed / low-overhead / more fine-grained and/or less 
hardware-architecture specific (future) alternatives.

For me, all of these are future options. In particular, when (1) 
abstractable for reduction of architectural dependencies, and hopefully 
(2) usable from both kernelspace and userspace.

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

Reduction (or getting rid) of preallocation strategies would be also a 
valuable feature for me.

Of course, I cannot decide what I will prefer in future for any future 
requirements. But some kind of mutual awareness and future collaboration 
would be great.