[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZMlcwrCMdZIBWT90@casper.infradead.org>
Date: Tue, 1 Aug 2023 20:28:02 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Rongwei Wang <rongwei.wang@...ux.alibaba.com>
Cc: linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org,
"xuyu@...ux.alibaba.com" <xuyu@...ux.alibaba.com>
Subject: Re: [PATCH RFC v2 0/4] Add support for sharing page tables across
processes (Previously mshare)
On Tue, Aug 01, 2023 at 02:53:02PM +0800, Rongwei Wang wrote:
>
> On 2023/8/1 00:38, Matthew Wilcox wrote:
> > On Mon, Jul 31, 2023 at 06:30:22PM +0200, David Hildenbrand wrote:
> > > Assume we do do the page table sharing at mmap time, if the flags are right.
> > > Let's focus on the most common:
> > >
> > > mmap(memfd, PROT_READ | PROT_WRITE, MAP_SHARED)
> > >
> > > And doing the same in each and every process.
> > That may be the most common in your usage, but for a database, you're
> > looking at two usage scenarios. Postgres calls mmap() on the database
> > file itself so that all processes share the kernel page cache.
> > Some Commercial Databases call mmap() on a hugetlbfs file so that all
> > processes share the same userspace buffer cache. Other Commecial
> > Databases call shmget() / shmat() with SHM_HUGETLB for the exact
> > same reason.
> >
> > This is why I proposed mshare(). Anyone can use it for anything.
>
> Hi Matthew
>
> I'm a little confused about this mshare(). Which one is the mshare() you
> refer to here, previous mshare() based on filesystem or this RFC v2 posted
> by Khalid?
>
> IMHO, they have much difference between previously mshare() and
> MAP_SHARED_PT now.
I haven't read this version of the patchset. I'm describing the original
idea, not what it may have turned into. As far as I'm concerned, we're
still trying to decide what functionality we actually want, not arguing
about whether this exact patchset has the correct number of tab indents
to be merged.
Powered by blists - more mailing lists