From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39720) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQ2Zo-0002Vv-BI for qemu-devel@nongnu.org; Fri, 05 Sep 2014 19:05:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XQ2Zn-0002Jk-6A for qemu-devel@nongnu.org; Fri, 05 Sep 2014 19:05:56 -0400 Received: from mail-oi0-x22e.google.com ([2607:f8b0:4003:c06::22e]:46343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQ2Zm-0002JU-54 for qemu-devel@nongnu.org; Fri, 05 Sep 2014 19:05:55 -0400 Received: by mail-oi0-f46.google.com with SMTP id h136so8235921oig.19 for ; Fri, 05 Sep 2014 16:05:53 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <540A35D5.4050708@redhat.com> References: <20140905135244.104423770@amt.cnet> <20140905182656.GA16828@amt.cnet> <540A35D5.4050708@redhat.com> From: Andrey Korolyov Date: Sat, 6 Sep 2014 03:05:33 +0400 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [patch 0/3] kvmclock: Ensure time in migration never goes backward (v3) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Marcelo Tosatti , =?UTF-8?Q?Marcin_Gibu=C3=85_a?= , "qemu-devel@nongnu.org" On Sat, Sep 6, 2014 at 2:14 AM, Paolo Bonzini wrote: > Il 05/09/2014 21:35, Andrey Korolyov ha scritto: >> - boot up a VM, make sure to feed it heavy long task, for example >> kernel compilation, >> - neither migrate once in the middle of process (with fallback to >> non-live migration which is available in libvirt, else it may take >> forever) or just wait up to the end, >> - live migration time degrades from sub-10s value to larger values >> forever, not regarding if workload is still presented or not. > > Are you sure you aren't simply doing migration with a low bandwidth > limit (the default is 32 MB/s), and moving over a gigabyte worth of page > cache data to the new machine? > > Paolo As far as I can see setspeed does not change anything over stdev variation for gigabit, but rss size does. Will check if this part is actually broken, because we are overriding default speed value every time and if it started being constant, it may explain such a difference.