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.
