On Sun, Aug 2, 2020 at 8:51 PM Matthew Wilcox [off-list ref] wrote:

On Sun, Aug 02, 2020 at 08:28:08PM -0700, John Hubbard wrote:

quoted

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