From: Matthew Wilcox <willy@infradead.org>
To: John Hubbard <jhubbard@nvidia.com>
Cc: Peter Collingbourne <pcc@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Evgenii Stepanov <eugenis@google.com>,
linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm: introduce reference pages
Date: Mon, 3 Aug 2020 04:51:13 +0100 [thread overview]
Message-ID: <20200803035113.GX23808@casper.infradead.org> (raw)
In-Reply-To: <92fa4a71-d8dc-0f07-832c-cbceca43e537@nvidia.com>
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.
next prev parent reply other threads:[~2020-08-03 3:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-31 20:32 [PATCH] mm: introduce reference pages Peter Collingbourne
2020-08-03 3:28 ` John Hubbard
2020-08-03 3:51 ` Matthew Wilcox [this message]
2020-08-13 22:03 ` Peter Collingbourne
2020-08-13 22:03 ` Peter Collingbourne
2020-08-03 9:32 ` Kirill A. Shutemov
2020-08-03 12:01 ` Catalin Marinas
2020-08-04 0:50 ` Peter Collingbourne
2020-08-04 15:27 ` Catalin Marinas
2020-08-04 15:48 ` Kirill A. Shutemov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200803035113.GX23808@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=eugenis@google.com \
--cc=jhubbard@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=pcc@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).