qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Amit Shah <amit.shah@redhat.com>
To: Liang Li <liang.z.li@intel.com>
Cc: mst@redhat.com, viro@zeniv.linux.org.uk,
	linux-kernel@vger.kernel.org, quintela@redhat.com,
	pbonzini@redhat.com, dgilbert@redhat.com, linux-mm@kvack.org,
	kvm@vger.kernel.org, qemu-devel@nongnu.org, agraf@suse.de,
	borntraeger@de.ibm.com
Subject: Re: [Qemu-devel] [PATCH kernel 0/2] speed up live migration by skipping free pages
Date: Mon, 25 Apr 2016 11:36:41 +0530	[thread overview]
Message-ID: <20160425060641.GC4735@grmbl.mre> (raw)
In-Reply-To: <1461076474-3864-1-git-send-email-liang.z.li@intel.com>

On (Tue) 19 Apr 2016 [22:34:32], Liang Li wrote:
> Current QEMU live migration implementation mark all guest's RAM pages
> as dirtied in the ram bulk stage, all these pages will be processed
> and it consumes quite a lot of CPU cycles and network bandwidth.
> 
> From guest's point of view, it doesn't care about the content in free
> page. We can make use of this fact and skip processing the free
> pages, this can save a lot CPU cycles and reduce the network traffic
> significantly while speed up the live migration process obviously.
> 
> This patch set is the kernel side implementation.
> 
> The virtio-balloon driver is extended to send the free page bitmap
> from guest to QEMU.
> 
> After getting the free page bitmap, QEMU can use it to filter out
> guest's free pages. This make the live migration process much more
> efficient.
> 
> In order to skip more free pages, we add an interface to let the user
> decide whether dropping the cache in guest during live migration.

So if virtio-balloon is the way to go (i.e. speed is acceptable), I
just have one point then.  My main concern with using (or not using)
virtio-balloon was that a guest admin is going to disable the
virtio-balloon driver entirely because the admin won't want the guest
to give away pages to the host, esp. when the guest is to be a
high-performant one.

In this case, if a new command can be added to the balloon spec where
a guest driver indicates it's not going to participate in ballooning
activity (ie a guest will ignore any ballooning requests from the
host), but use the driver just for stats-sharing purposes, that can be
a workable solution here as well.  In that case, we can keep the
MM-related stuff inside the balloon driver, and also get the benefit
of the guest having control over how it uses its memory,
disincentivising guest admins from disabling the balloon entirely (it
will also benefit the guest to keep this driver loaded in such a
state, if migration is faster!).

		Amit

  parent reply	other threads:[~2016-04-25  6:06 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-19 14:34 [Qemu-devel] [PATCH kernel 0/2] speed up live migration by skipping free pages Liang Li
2016-04-19 14:34 ` [Qemu-devel] [PATCH kernel 1/2] mm: add the related functions to build the free page bitmap Liang Li
2016-04-19 14:54   ` Rik van Riel
2016-04-19 15:02     ` Li, Liang Z
2016-04-19 15:26       ` Rik van Riel
2016-04-20  0:57         ` Li, Liang Z
2016-04-19 16:15       ` Michael S. Tsirkin
2016-04-20  1:41         ` Li, Liang Z
2016-04-21 13:48           ` Michael S. Tsirkin
2016-04-22  1:36             ` Li, Liang Z
2016-04-22  9:48         ` Dr. David Alan Gilbert
2016-04-22 13:58           ` Michael S. Tsirkin
2016-04-25  3:11             ` Li, Liang Z
2016-04-25 10:43               ` Michael S. Tsirkin
2016-04-26  3:21                 ` Li, Liang Z
2016-04-19 14:56   ` kbuild test robot
2016-04-19 16:01   ` kbuild test robot
2016-04-19 16:14   ` kbuild test robot
2016-04-19 14:34 ` [Qemu-devel] [PATCH kernel 2/2] virtio-balloon: extend balloon driver to support the new feature Liang Li
2016-04-19 16:18   ` Michael S. Tsirkin
2016-04-25  6:06 ` Amit Shah [this message]
2016-04-25 11:04   ` [Qemu-devel] [PATCH kernel 0/2] speed up live migration by skipping free pages Michael S. Tsirkin
2016-04-25 12:08     ` Amit Shah
2016-04-25 12:51       ` Michael S. Tsirkin
2016-04-25 13:17         ` Dr. David Alan Gilbert

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=20160425060641.GC4735@grmbl.mre \
    --to=amit.shah@redhat.com \
    --cc=agraf@suse.de \
    --cc=borntraeger@de.ibm.com \
    --cc=dgilbert@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=liang.z.li@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /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).