From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33460) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dckNM-00062S-F3 for qemu-devel@nongnu.org; Tue, 01 Aug 2017 23:31:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dckNJ-0003bv-5V for qemu-devel@nongnu.org; Tue, 01 Aug 2017 23:31:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45540) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dckNI-0003bQ-V3 for qemu-devel@nongnu.org; Tue, 01 Aug 2017 23:31:09 -0400 Date: Wed, 2 Aug 2017 11:31:02 +0800 From: Peter Xu Message-ID: <20170802033102.GC15080@pxdev.xzpeter.org> References: <1501229198-30588-1-git-send-email-peterx@redhat.com> <1501229198-30588-11-git-send-email-peterx@redhat.com> <20170731185224.GB3095@work-vm> <20170801031303.GE15697@pxdev.xzpeter.org> <20170801085001.GB2079@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170801085001.GB2079@work-vm> Subject: Re: [Qemu-devel] [RFC 10/29] migration: new property "x-postcopy-fast" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: qemu-devel@nongnu.org, Laurent Vivier , Alexey Perevalov , Juan Quintela , Andrea Arcangeli On Tue, Aug 01, 2017 at 09:50:02AM +0100, Dr. David Alan Gilbert wrote: > * Peter Xu (peterx@redhat.com) wrote: > > On Mon, Jul 31, 2017 at 07:52:24PM +0100, Dr. David Alan Gilbert wrote: > > > * Peter Xu (peterx@redhat.com) wrote: > > > > This provides a way to start postcopy ASAP when migration starts. To do > > > > this, we need both: > > > > > > > > -global migration.x-postcopy-ram=on \ > > > > -global migration.x-postcopy-fast=on > > > > > > Can you explain why this is necessary? Both sides already know > > > they're doing a postcopy recovery don't they? > > > > What I wanted to do here is to provide a way to start postcopy at the > > very beginning (actually it'll possibly start postcopy at the first > > loop in migration_thread), instead of start postcopy until we trigger > > it using "migrate_start_postcopy" command. > > > > I used it for easier debugging (so I don't need to type > > "migrate_start_postcopy" every time when I trigger postcopy > > migration), meanwhile I think it can also be used when someone really > > want to start postcopy from the very beginning. > > > > Would such a new parameter makes sense? > > Other than debugging, I don't think there's a real use for it; the > slight delay between starting migration and triggering postcopy has > very little cost. Then let me drop this patch in next version. I do think I should avoid introducing too many things "for debugging only"... -- Peter Xu