Subject: Re: [Qemu-devel] [PATCH 00/15] Make migration work with hotplug
From: Alex Williamson <alex.williamson@redhat.com>
In-Reply-To: <AANLkTilbStX3nKh4PcJxDbDjbyzBdL7QLJ2y2prR3YYi@mail.gmail.com>
References: <20100624044046.16168.32804.stgit@localhost.localdomain>
	<AANLkTilbStX3nKh4PcJxDbDjbyzBdL7QLJ2y2prR3YYi@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 24 Jun 2010 09:04:30 -0600
Message-ID: <1277391870.4669.2251.camel@x201>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
To: Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>
Cc: jan.kiszka@siemens.com, qemu-devel@nongnu.org, armbru@redhat.com, paul@codesourcery.com, cam@cs.ualberta.ca, kraxel@redhat.com

On Thu, 2010-06-24 at 15:02 +0900, Yoshiaki Tamura wrote:
> 
> Hi Alex,
> 
> Is there additional overhead to save rams introduce by this series?
> If so, how much?

Yes, there is overhead, but it's typically quite small.  If I migrate a
1G VM immediately after I boot to a login prompt (lots of zero pages), I
get an overhead of 0.000076%.  That's only 226 extra bytes over the
297164995 bytes otherwise transferred.  If I build a kernel on the guest
and migrate during the compilation, the overhead is 0.000019%.  The
overhead is tiny largely due to patch 12/15, which avoids sending the
block name if we're working within the same block as sent previously.
If I disable this optimization, the overhead goes up to 0.93% after boot
and 0.26% during a kernel compile.

Note that an x86 VM does a separate qemu_ram_alloc for memory above 4G,
which means in bigger VMs we may end up needing to resend the ramblock
name once in a while as we bounce between above and below 4G.  Worst
case for this could match the 0.26% above, but in my testing during a
kernel compile, this seems to increase the overhead to 0.000026% on a 6G
VM.  I don't see any reason why we couldn't allocate all the ram in a
single qemu_ram_alloc call, so I'll add another patch to make that
change (which will also shorten the name to "pc.ram" for even less
overhead ;).  Thanks,

Alex