From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37914) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZdRS-0007M4-RL for qemu-devel@nongnu.org; Fri, 25 Oct 2013 05:12:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZdRM-0008OT-Qp for qemu-devel@nongnu.org; Fri, 25 Oct 2013 05:12:26 -0400 Received: from mail-wg0-f52.google.com ([74.125.82.52]:52334) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZdRM-0008OF-H9 for qemu-devel@nongnu.org; Fri, 25 Oct 2013 05:12:20 -0400 Received: by mail-wg0-f52.google.com with SMTP id f12so3509093wgh.31 for ; Fri, 25 Oct 2013 02:12:19 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <526A1DF8.2040406@redhat.com> References: <1382412341-1173-1-git-send-email-lilei@linux.vnet.ibm.com> <52692C10.3080604@redhat.com> <526A0870.3020401@linux.vnet.ibm.com> <526A1DF8.2040406@redhat.com> Date: Fri, 25 Oct 2013 10:12:18 +0100 Message-ID: From: Anthony Liguori Content-Type: multipart/alternative; boundary=001a11c25cecb39a6004e98d25f6 Subject: Re: [Qemu-devel] [PATCH 0/17 v2] Localhost migration with side channel for ram List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Andrea Arcangeli , Lei Li , quintela@redhat.com, mdroth@linux.vnet.ibm.com, mrhines@linux.vnet.ibm.com, qemu-devel , Anthony Liguori , lagarcia@br.ibm.com, rcj@linux.vnet.ibm.com --001a11c25cecb39a6004e98d25f6 Content-Type: text/plain; charset=ISO-8859-1 On Oct 25, 2013 8:30 AM, "Paolo Bonzini" wrote: > > Il 25/10/2013 06:58, Lei Li ha scritto: > > Right now just has inaccurate numbers without the new vmsplice, which > > based on > > the result from info migrate, as the guest ram size increases, although the > > 'total time' is number of times less compared with the current live > > migration, but the 'downtime' performs badly. > > Of course. > > > > For a 1GB ram guest, > > > > total time: 702 milliseconds > > downtime: 692 milliseconds > > > > And when the ram size of guest increasesexponentially, those numbers are > > proportional to it. > > > > I will make a list of the performance with the new vmsplice later, I am > > sure it'd be much better than this at least. > > Yes, please. Is the memory usage is still 2x without vmsplice? > > I think you have a nice proof of concept, but on the other hand this > probably needs to be coupled with some kind of postcopy live migration, > that is: > > * the source starts sending data > > * but the destination starts running immediately > > * if the machine needs a page that is missing, the destination asks the > source to send it > > * as soon as it arrives, the destination can restart > > Using postcopy is problematic for reliability: if the destination fails, > the virtual machine is lost because the source doesn't have the latest > content of memory. However, this is a much, much smaller problem for > live QEMU upgrade where the network cannot fail. > > If you do this, you can achieve pretty much instantaneous live upgrade, > well within your original 200 ms goals. This is actually a very nice justification for post copy. Regards, Anthony Liguori But the flipping code with > vmsplice should be needed anyway to avoid doubling memory usage, and > it's looking pretty good in this version already! I'm relieved that the > RDMA code was designed right! > > Paolo > > --001a11c25cecb39a6004e98d25f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Oct 25, 2013 8:30 AM, "Paolo Bonzini" <pbonzini@redhat.com> wrote:
>
> Il 25/10/2013 06:58, Lei Li ha scritto:
> > Right now just has inaccurate numbers without the new vmsplice, w= hich
> > based on
> > the result from info migrate, as the guest ram size increases, al= though the
> > 'total time' is number of times less compared with the cu= rrent live
> > migration, but the 'downtime' performs badly.
>
> Of course.
> >
> > For a 1GB ram guest,
> >
> > total time: 702 milliseconds
> > downtime: 692 milliseconds
> >
> > And when the ram size of guest increasesexponentially, those numb= ers are
> > proportional to it.
> >
> > I will make a list of the performance with the new vmsplice later= , I am
> > sure it'd be much better than this at least.
>
> Yes, please. =A0Is the memory usage is still 2x without vmsplice?
>
> I think you have a nice proof of concept, but on the other hand this > probably needs to be coupled with some kind of postcopy live migration= ,
> that is:
>
> * the source starts sending data
>
> * but the destination starts running immediately
>
> * if the machine needs a page that is missing, the destination asks th= e
> source to send it
>
> * as soon as it arrives, the destination can restart
>
> Using postcopy is problematic for reliability: if the destination fail= s,
> the virtual machine is lost because the source doesn't have the la= test
> content of memory. =A0However, this is a much, much smaller problem fo= r
> live QEMU upgrade where the network cannot fail.
>
> If you do this, you can achieve pretty much instantaneous live upgrade= ,
> well within your original 200 ms goals. =A0

This is actually a very nice justification for post copy.

Regards,

Anthony Liguori

But the flipping code with
> vmsplice should be needed anyway to avoid doubling memory usage, and > it's looking pretty good in this version already! =A0I'm relie= ved that the
> RDMA code was designed right!
>
> Paolo
>
>

--001a11c25cecb39a6004e98d25f6--