LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Tiberiu Georgescu <firstname.lastname@example.org>
To: "Eric W. Biederman" <email@example.com>
Cc: Andrew Morton <firstname.lastname@example.org>,
Peter Xu <email@example.com>,
David Hildenbrand <firstname.lastname@example.org>,
Miaohe Lin <email@example.com>,
Alistair Popple <firstname.lastname@example.org>,
Ivan Teterevkov <email@example.com>,
Florian Schmidt <firstname.lastname@example.org>,
"Carl Waldspurger [C]" <email@example.com>,
Jonathan Davies <firstname.lastname@example.org>
Subject: Re: [PATCH 0/1] pagemap: swap location for shared pages
Date: Mon, 2 Aug 2021 12:20:17 +0000 [thread overview]
Message-ID: <6EEF4945-0574-4F24-A950-1DB292F698BC@nutanix.com> (raw)
> On 30 Jul 2021, at 18:28, Eric W. Biederman <email@example.com> wrote:
> Tiberiu A Georgescu <firstname.lastname@example.org> writes:
>> This patch follows up on a previous RFC:
>> When a page allocated using the MAP_SHARED flag is swapped out, its pagemap
>> entry is cleared. In many cases, there is no difference between swapped-out
>> shared pages and newly allocated, non-dirty pages in the pagemap
> What is the point?
The reason why this patch is important has been discussed in my RFC
patch and on this thread:
The most relevant reply should be Ivan's:
In short, this swap information helps us enhance live migration in some cases.
> You say a shared swapped out page is the same as a clean shared page
> and you are exactly correct. What is the point in knowing a shared
> page was swapped out? What does is the gain?
What I meant was that shared swapped out pages and clean shared pages
have their ptes identical pre-patch. I understand they are somewhat similar
concepts when it comes to file shared pages, where swapping is done
directly on the disk.
Our case focuses on anonymous pages and shared pages with identical
underlying behaviour (like pages allocated using memfd). These pages get
cleared once the runtime is over, and the difference between allocated,
but uninitialised pages, and dirty pages that have been swapped out is
significant, as the former could still contain usable data.
The post-patch pagemap entry now contains the swap type and offset for
swapped out pages, regardless of whether the page is private or shared.
This, by definition of the pagemap, should be the correct behaviour.
> I tried to understand the point by looking at your numbers below
> and everything I could see looked worse post patch.
Indeed, the numbers are mostly bigger post-patch. It is a tradeoff between
correctness and performance. However, the tradeoff is not inconvenient on sparse
single accesses, and it can be made significantly faster by leveraging batching.
In future work, the performance can be improved by leveraging a mechanism
proposed by Peter Xu: Special PTEs:
The main concern of the RFC was that the xarray check would slow down
checking empty pages significantly. Thankfully, we can only see a small
overhead when no allocated shared page is dirtied.
Hope I was able to clarifiy a few things. Now, having laid out the context,
please have another look at my proposed patch.
next prev parent reply other threads:[~2021-08-02 12:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-30 16:08 Tiberiu A Georgescu
2021-07-30 16:08 ` [PATCH 1/1] pagemap: report " Tiberiu A Georgescu
2021-07-30 17:28 ` [PATCH 0/1] pagemap: " Eric W. Biederman
2021-08-02 12:20 ` Tiberiu Georgescu [this message]
2021-08-04 18:33 ` Peter Xu
2021-08-04 18:49 ` David Hildenbrand
2021-08-04 19:17 ` Peter Xu
2021-08-11 16:15 ` David Hildenbrand
2021-08-11 16:17 ` David Hildenbrand
2021-08-11 18:25 ` Peter Xu
2021-08-11 18:41 ` David Hildenbrand
2021-08-11 19:54 ` Peter Xu
2021-08-11 20:13 ` David Hildenbrand
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH 0/1] pagemap: swap location for shared pages' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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).