kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Matlack <dmatlack@google.com>
To: Janis Schoetterl-Glausch <scgl@linux.vnet.ibm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	kvm list <kvm@vger.kernel.org>, Ben Gardon <bgardon@google.com>,
	Junaid Shahid <junaids@google.com>,
	Sean Christopherson <seanjc@google.com>,
	Oliver Upton <oupton@google.com>,
	Harish Barathvajasankar <hbarath@google.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Peter Xu <peterx@redhat.com>,
	Peter Shier <pshier@google.com>
Subject: Re: RFC: KVM: x86/mmu: Eager Page Splitting
Date: Mon, 8 Nov 2021 21:07:51 +0000	[thread overview]
Message-ID: <YYmRpz4dQgli3GKM@google.com> (raw)
In-Reply-To: <bc06dd82-06e1-b455-b2c1-59125b530dda@linux.vnet.ibm.com>

On Fri, Nov 05, 2021 at 06:17:11PM +0100, Janis Schoetterl-Glausch wrote:
> On 11/4/21 23:45, David Matlack wrote:
> 
> [...]
> > 
> > The last alternative is to perform dirty tracking at a 2M granularity.
> > This would reduce the amount of splitting work required by 512x,
> > making the current approach of splitting on fault less impactful to
> > customer performance. We are in the early stages of investigating 2M
> > dirty tracking internally but it will be a while before it is proven
> > and ready for production. Furthermore there may be scenarios where
> > dirty tracking at 4K would be preferable to reduce the amount of
> > memory that needs to be demand-faulted during precopy.

Oops I meant to say "demand-faulted during post-copy" here.

> I'm curious how you're going about evaluating this, as I've experimented with
> 2M dirty tracking in the past, in a continuous checkpointing context however.
> I suspect it's very sensitive to the workload. If the coarser granularity
> leads to more memory being considered dirty, the length of pre-copy rounds
> increases, giving the workload more time to dirty even more memory.
> Ideally large pages would be used only for regions that won't be dirty or
> regions that would also be pretty much completely dirty when tracking at 4K.
> But deciding the granularity adaptively is hard, doing 2M tracking instead
> of 4K robs you of the very information you'd need to judge that.

We're planning to look at how 2M tracking affects the amount of memory
that needs to be demand-faulted during the post-copy phase for different
workloads.

  reply	other threads:[~2021-11-08 21:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-04 22:45 RFC: KVM: x86/mmu: Eager Page Splitting David Matlack
2021-11-05  8:44 ` Paolo Bonzini
2021-11-08 19:57   ` David Matlack
2021-11-08 21:37     ` Paolo Bonzini
2021-11-08 21:39       ` David Matlack
2021-11-05 17:17 ` Janis Schoetterl-Glausch
2021-11-08 21:07   ` David Matlack [this message]
2021-11-23 12:15     ` Peter Xu

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=YYmRpz4dQgli3GKM@google.com \
    --to=dmatlack@google.com \
    --cc=bgardon@google.com \
    --cc=hbarath@google.com \
    --cc=jmattson@google.com \
    --cc=junaids@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=oupton@google.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=pshier@google.com \
    --cc=scgl@linux.vnet.ibm.com \
    --cc=seanjc@google.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.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).