From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41096) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZI9Si-0004UR-Ef for qemu-devel@nongnu.org; Thu, 23 Jul 2015 01:54:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZI9SZ-0001cS-FJ for qemu-devel@nongnu.org; Thu, 23 Jul 2015 01:54:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37697) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZI9SZ-0001bl-9y for qemu-devel@nongnu.org; Thu, 23 Jul 2015 01:54:23 -0400 Date: Thu, 23 Jul 2015 11:23:55 +0530 From: Amit Shah Message-ID: <20150723054703.GM10280@grmbl.mre> References: <1434450415-11339-1-git-send-email-dgilbert@redhat.com> <1434450415-11339-29-git-send-email-dgilbert@redhat.com> <87a8v0jjvt.fsf@neno.neno> <20150713175654.GM2492@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150713175654.GM2492@work-vm> Subject: Re: [Qemu-devel] [PATCH v7 28/42] Postcopy: Postcopy startup in migration thread List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: aarcange@redhat.com, yamahata@private.email.ne.jp, Juan Quintela , liang.z.li@intel.com, qemu-devel@nongnu.org, luis@cs.umu.se, pbonzini@redhat.com, david@gibson.dropbear.id.au On (Mon) 13 Jul 2015 [18:56:55], Dr. David Alan Gilbert wrote: > * Juan Quintela (quintela@redhat.com) wrote: > > > + /* > > > + * send rest of state - note things that are doing postcopy > > > + * will notice we're in POSTCOPY_ACTIVE and not actually > > > + * wrap their state up here > > > + */ > > > + qemu_file_set_rate_limit(ms->file, INT64_MAX); > > > > Do we undo this? or, are we sure that it is ok to maximize network > > output? > > No we don't undo it; it's a good question what we can do better. > I'm trying to avoid delaying the postcopy-requested pages; ideally > I'd like to separate those out so they get satisfied but still > meet the bandwidth limit for the background transfer. > The ideal is separate fd's, however something else I've considered > is getting incoming postcopy requests to wake the outgoing side > up when it's sleeping for the bandwidth limit, although I've > not tried implementing that yet. Might be a conflict in the knobs we expose (max_bandwidth) and us not adhering to that. I agree we want this to go full-throttle, so maybe document that postcopy will override that knob? It's tricky to get everyone to understand that postcopy will do that. Plus there'll be other questions like what else does postcopy override? -- not that there's anythign more, but users will wonder. Amit