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:   Wed, 26 Jan 2022 04:04:48 +0000
From:   Matthew Wilcox <willy@infradead.org>
To:     "Kirill A. Shutemov" <kirill@shutemov.name>
Cc:     Khalid Aziz <khalid.aziz@oracle.com>, akpm@linux-foundation.org,
        longpeng2@huawei.com, arnd@arndb.de, dave.hansen@linux.intel.com,
        david@redhat.com, rppt@kernel.org, surenb@google.com,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC PATCH 0/6] Add support for shared PTEs across processes
Message-ID: <YfDIYKygRHX4RIri@casper.infradead.org>
References: <cover.1642526745.git.khalid.aziz@oracle.com>
 <20220125114212.ks2qtncaahi6foan@box.shutemov.name>
 <Ye/5yUyEqO0ws0G5@casper.infradead.org>
 <20220125135917.ezi6itozrchsdcxg@box.shutemov.name>
 <YfAEqzTeBJSIOKcA@casper.infradead.org>
 <20220125185705.wf7p2l77vggipfry@box.shutemov.name>
 <YfBIpmxvc0+mFByf@casper.infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YfBIpmxvc0+mFByf@casper.infradead.org>
Precedence: bulk

On Tue, Jan 25, 2022 at 06:59:50PM +0000, Matthew Wilcox wrote:
> On Tue, Jan 25, 2022 at 09:57:05PM +0300, Kirill A. Shutemov wrote:
> > On Tue, Jan 25, 2022 at 02:09:47PM +0000, Matthew Wilcox wrote:
> > > > I think zero-API approach (plus madvise() hints to tweak it) is worth
> > > > considering.
> > > 
> > > I think the zero-API approach actually misses out on a lot of
> > > possibilities that the mshare() approach offers.  For example, mshare()
> > > allows you to mmap() many small files in the shared region -- you
> > > can't do that with zeroAPI.
> > 
> > Do you consider a use-case for many small files to be common? I would
> > think that the main consumer of the feature to be mmap of huge files.
> > And in this case zero enabling burden on userspace side sounds like a
> > sweet deal.
> 
> mmap() of huge files is certainly the Oracle use-case.  With occasional
> funny business like mprotect() of a single page in the middle of a 1GB
> hugepage.

Bill and I were talking about this earlier and realised that this is
the key point.  There's a requirement that when one process mprotects
a page that it gets protected in all processes.  You can't do that
without *some* API because that's different behaviour than any existing
API would produce.

So how about something like this ...

int mcreate(const char *name, int flags, mode_t mode);

creates a new mm_struct with a refcount of 2.  returns an fd (one
of the two refcounts) and creates a name for it (inside msharefs,
holds the other refcount).

You can then mmap() that fd to attach it to a chunk of your address
space.  Once attached, you can start to populate it by calling
mmap() and specifying an address inside the attached mm as the first
argument to mmap().

Maybe mcreate() is just a library call, and it's really a thin wrapper
around open() that happens to know where msharefs is mounted.