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