From: Paolo Bonzini <pbonzini@redhat.com>
To: Ben Gardon <bgardon@google.com>, yulei zhang <yulei.kernel@gmail.com>
Cc: Wanpeng Li <kernellwp@gmail.com>, kvm <kvm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Sean Christopherson <sean.j.christopherson@intel.com>,
Jim Mattson <jmattson@google.com>,
Junaid Shahid <junaids@google.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Xiao Guangrong <xiaoguangrong.eric@gmail.com>,
Haiwei Li <lihaiwei.kernel@gmail.com>
Subject: Re: [RFC V2 0/9] x86/mmu:Introduce parallel memory virtualization to boost performance
Date: Fri, 25 Sep 2020 22:50:07 +0200 [thread overview]
Message-ID: <2592097d-3190-1862-b438-9e1b16616b82@redhat.com> (raw)
In-Reply-To: <CANgfPd-ZRW676grgOmm2E2+_RtFaiJfspnKseHMKgsHGfepmig@mail.gmail.com>
On 25/09/20 19:30, Ben Gardon wrote:
> Oh, thank you for explaining that. I didn't realize the goal here was
> to improve LM performance. I was under the impression that this was to
> give VMs a better experience on startup for fast scaling or something.
> In your testing with live migration how has this affected the
> distribution of time between the phases of live migration? Just for
> terminology (since I'm not sure how standard it is across the
> industry) I think of a live migration as consisting of 3 stages:
> precopy, blackout, and postcopy. In precopy we're tracking the VM's
> working set via dirty logging and sending the contents of its memory
> to the target host. In blackout we pause the vCPUs on the source, copy
> minimal data to the target, and resume the vCPUs on the target. In
> postcopy we may still have some pages that have not been copied to the
> target and so request those in response to vCPU page faults via user
> fault fd or some other mechanism.
>
> Does EPT pre-population preclude the use of a postcopy phase?
I think so.
As a quick recap, turn postcopy migration handles two kinds of
pages---they can be copied to the destination either in background
(stuff that was dirty when userspace decided to transition to the
blackout phase) or on-demand (relayed from KVM to userspace via
get_user_pages and userfaultfd). Normally only on-demand pages would be
served through userfaultfd, while with prepopulation every missing page
would be faulted in from the kernel through userfaultfd. In practice
this would just extend the blackout phase.
Paolo
> I would
> expect that to make the blackout phase really long. Has that not been
> a problem for you?
>
> I love the idea of partial EPT pre-population during precopy if you
> could still handle postcopy and just pre-populate as memory came in.
>
next prev parent reply other threads:[~2020-09-25 20:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-01 11:52 yulei.kernel
2020-09-01 11:54 ` [RFC V2 1/9] Introduce new fields in kvm_arch/vcpu_arch struct for direct build EPT support yulei.kernel
2020-09-01 11:55 ` [RFC V2 2/9] Introduce page table population function for direct build EPT feature yulei.kernel
2020-09-01 11:55 ` [RFC V2 3/9] Introduce page table remove " yulei.kernel
2020-09-01 11:55 ` [RFC V2 4/9] Add release function for direct build ept when guest VM exit yulei.kernel
2020-09-01 11:56 ` [RFC V2 5/9] Modify the page fault path to meet the direct build EPT requirement yulei.kernel
2020-09-01 11:56 ` [RFC V2 6/9] Apply the direct build EPT according to the memory slots change yulei.kernel
2020-09-01 11:56 ` [RFC V2 7/9] Add migration support when using direct build EPT yulei.kernel
2020-09-01 11:57 ` [RFC V2 8/9] Introduce kvm module parameter global_tdp to turn on the direct build EPT mode yulei.kernel
2020-09-01 11:57 ` [RFC V2 9/9] Handle certain mmu exposed functions properly while turn on " yulei.kernel
2020-09-09 3:04 ` [RFC V2 0/9] x86/mmu:Introduce parallel memory virtualization to boost performance Wanpeng Li
2020-09-24 6:28 ` Wanpeng Li
2020-09-24 17:14 ` Ben Gardon
2020-09-25 12:04 ` yulei zhang
2020-09-25 17:30 ` Ben Gardon
2020-09-25 20:50 ` Paolo Bonzini [this message]
2020-09-28 11:52 ` yulei zhang
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=2592097d-3190-1862-b438-9e1b16616b82@redhat.com \
--to=pbonzini@redhat.com \
--cc=bgardon@google.com \
--cc=jmattson@google.com \
--cc=junaids@google.com \
--cc=kernellwp@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=lihaiwei.kernel@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sean.j.christopherson@intel.com \
--cc=vkuznets@redhat.com \
--cc=xiaoguangrong.eric@gmail.com \
--cc=yulei.kernel@gmail.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
all inboxes | Powered by JetHome®