[PATCH] mm: introduce reference pages

[Peter Collingbourne]

On Sun, Aug 2, 2020 at 8:51 PM Matthew Wilcox <willy at 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