From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37221) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkEqf-0007gl-NM for qemu-devel@nongnu.org; Sun, 16 Dec 2012 09:05:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TkEqe-0002AA-9V for qemu-devel@nongnu.org; Sun, 16 Dec 2012 09:05:45 -0500 Received: from mail-wi0-f171.google.com ([209.85.212.171]:63649) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkEqe-0002A5-24 for qemu-devel@nongnu.org; Sun, 16 Dec 2012 09:05:44 -0500 Received: by mail-wi0-f171.google.com with SMTP id hn14so1404667wib.10 for ; Sun, 16 Dec 2012 06:05:42 -0800 (PST) Sender: Paolo Bonzini Message-ID: <50CDD532.6020402@redhat.com> Date: Sun, 16 Dec 2012 15:05:38 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1941762316.24986459.1355562148249.JavaMail.root@redhat.com> <50CC5CF2.2040606@dlhnet.de> In-Reply-To: <50CC5CF2.2040606@dlhnet.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] big wait check in ram_save_iterate() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: Kevin Wolf , qemu-devel@nongnu.org, quintela@redhat.com Il 15/12/2012 12:20, Peter Lieven ha scritto: > Am 15.12.2012 10:02, schrieb Paolo Bonzini: >> >>> is the check for spending > 50ms in the loop still necessary in qemu >>> 1.3.0? >> >> Yes, it helps finding the available bandwidth and tuning the downtime of >> migration. > > Aha, okay. But then it should also be added to block migration, shoudn't it? The main problem with block migration is that it uses the same strategy for RAM and storage migration, but the two are very different. In RAM migration, you are basically fighting an uphill battle. You cannot do RAM migration without some amount of downtime, because CPUs are always going to be faster than the migration process and latency is zero. But in storage migration you have the same constraints as the guest. Disk is slow for the guest too (and as slow as network, or slower). The guest needs to flush to disk, while the migration process does not need to do that. And migration can proceed asynchronously, just like the guest, with multiple in-flight operations at the same time. drive-mirror can do all this much better than migration, and without slowing down RAM migration (which occurs on a separate socket). See the drive-mirror patches that I posted recently for 1.4. With those patches, I can sync the destination to the source every 100 ms during a kernel compilation, and every 1-2 seconds during hibernation (the absolute worst case) using iSCSI for both the source and the target and a middle-range SAS disk. This is a far cry from what RAM migration can achieve on any reasonable workload, and it's the reason why I'm pushing for a separate mechanism than the migrate command. libvirt has had patches posted to support this too. Paolo > I tested it in qemu-kvm 1.2.0 and it help to increase responsiveness if the > I/O latency on the storage is high.