Re: [PATCH] mm: introduce reference pages

From: Peter Collingbourne <pcc@google.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: John Hubbard <jhubbard@nvidia.com>,
	linux-mm@kvack.org, Evgenii Stepanov <eugenis@google.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] mm: introduce reference pages
Date: Thu, 13 Aug 2020 15:03:47 -0700	[thread overview]
Message-ID: <CAMn1gO5f8mRBPdJ3bTAjPgo_8yBhjtifX2rw+cut6vYmZmTZKQ@mail.gmail.com> (raw)
In-Reply-To: <20200803035113.GX23808@casper.infradead.org>

On Sun, Aug 2, 2020 at 8:51 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Sun, Aug 02, 2020 at 08:28:08PM -0700, John Hubbard wrote:
> > This will end up overflowing the page->_refcount in some situations.
> >
> > Some thoughts:
> >
> > In order to implement this feature, the reference pages need to be made
> > at least a little bit more special, and probably little bit more like
> > zero pages. At one extreme, for example, zero pages could be a special
> > case of reference pages, although I'm not sure of a clean way to
> > implement that.
> >
> >
> > The reason that more special-ness is required, is that things such as
> > reference counting and locking can be special-cased with zero pages.
> > Doing so allows avoiding page->_refcount overflows, for example. Your
> > patch here, however, allows normal pages to be treated *almost* like a
> > zero page, in that it's a page full of constant value data. But because
> > a refpage can be any page, not just a special one that is defined at a
> > single location, that leads to problems with refcounts.
>
> We could bump the refcount on mmap and only put it on munmap.  That
> complexifies a few more paths which now need to check for the VMA special
> page as well as the zero page on pte unmap.
>
> Perhaps a better way around this is that the default page can only be one
> of the pages in the mmap ... and that page is duplicated (not shared) on
> fork().  That way the refcount is at most the number of pages in the mmap.
> And if we constrain the size of these mappings to be no more than 8TB,
> that constrains the refcount on this page to be no more than 2^31.

I'm not a fan of this idea to be honest. It means that we need to
spend a page per mapping to get this behavior, instead of a page
across the entire process. And in an allocator like scudo we can end
up making a lot of mappings. I think there would also be complexities
around VMA splitting, which would probably mean that these mappings
become special enough that we don't gain much with this approach.

Thanks,
Peter

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel