From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42932) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5S5e-00030n-RS for qemu-devel@nongnu.org; Fri, 11 Jul 2014 00:05:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X5S5V-0006Dg-NX for qemu-devel@nongnu.org; Fri, 11 Jul 2014 00:05:42 -0400 Received: from mail-pa0-x231.google.com ([2607:f8b0:400e:c03::231]:34681) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5S5V-0006Db-GI for qemu-devel@nongnu.org; Fri, 11 Jul 2014 00:05:33 -0400 Received: by mail-pa0-f49.google.com with SMTP id lj1so703907pab.36 for ; Thu, 10 Jul 2014 21:05:32 -0700 (PDT) Message-ID: <53BF6279.5030803@gmail.com> Date: Fri, 11 Jul 2014 09:35:13 +0530 From: Sanidhya Kashyap MIME-Version: 1.0 References: <1404495717-4239-1-git-send-email-dgilbert@redhat.com> <53B7D36B.4050800@redhat.com> <20140707140229.GA3443@work-vm> <53BAB03B.5000308@redhat.com> <20140710112921.GG2627@work-vm> <53BE8B8E.5020505@redhat.com> <20140710133742.GH2627@work-vm> <20140710153305.GA20989@redhat.com> <20140710154944.GI2627@work-vm> In-Reply-To: <20140710154944.GI2627@work-vm> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 00/46] Postcopy implementation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: Andrea Arcangeli , yamahata@private.email.ne.jp, lilei@linux.vnet.ibm.com, quintela@redhat.com, qemu-devel@nongnu.org, Paolo Bonzini >> The single precopy lazy pass would consist of clearing the dirty >> bitmap, starting precopy, then if any page is found dirty by the time >> precopy tries to send it, we skip it. We only send those pages in >> precopy that haven't been modified yet by the time we reach them in >> precopy. >> >> Pages heavily modified will be sent purely through >> postcopy. Ultimately postcopy will be a page sorting feature to >> massively decrease the downtime latency, and to reduce to 2*ramsize >> the maximum amount of data transferred on the network without having >> to slow down the guest artificially. We'll also know exactly the >> maximum time in advance that it takes to migrate a large host no >> matter the load in it (2*ramsize divided by the network bandwidth >> available at the migration time). It'll be totally deterministic, no >> black magic slowdowns anymore. > > There is a trade off; killing the precopy does reduce network bandwidth, > but the other side of it is that you would incur more postcopy round trips, > so your average latency will probably increase. > I agree with David on the latency issue. I (along with my colleague) have tried the idea of single iteration precopy and then postcopy (with our own version of pre+post implementation). In case of workloads with huge writable working set size, the VM remains a bit inactive, because of transfer of pages. We coined a new term i.e. perceivable downtime, which can be measured for workloads running some network intensive tasks. The multiple postcopy round trips will certainly worsen the performance of a memory intensive workload like mcf of SPECCPU 2006 or even memcached based guest is migrated (some of the workloads on which we tested our prototype). Currently, I don't know how does David's postcopy implementation handles multiple pages, which I will try to investigate in sometime. -- Sanidhya