From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bag0u-0003aS-Tb for qemu-devel@nongnu.org; Fri, 19 Aug 2016 05:22:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bag0p-0002F5-SS for qemu-devel@nongnu.org; Fri, 19 Aug 2016 05:22:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36026) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bag0p-0002Eq-Mb for qemu-devel@nongnu.org; Fri, 19 Aug 2016 05:22:51 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1318D821C3 for ; Fri, 19 Aug 2016 09:22:51 +0000 (UTC) Date: Fri, 19 Aug 2016 17:22:46 +0800 From: Peter Xu Message-ID: <20160819092246.GB746@pxdev.xzpeter.org> References: <20160819065037.GA32302@pxdev.xzpeter.org> <20160819081315.GA2004@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160819081315.GA2004@work-vm> Subject: Re: [Qemu-devel] Question with migrate_set_speed List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: QEMU Devel Mailing List , "Daniel P. Berrange" , quintela@redhat.com, Amit Shah On Fri, Aug 19, 2016 at 09:13:15AM +0100, Dr. David Alan Gilbert wrote: > Actually, that's what QEMU does; the migrate_set_speed is really only used > for (1) directly. > (2) actually comes from a measured bandwidth multiplied by the 'migrate_set_downtime' > figure. (See around line 1800ish i migration/migration.c inside > the if (current_time >= initial+time + BUFFER_DELAY) if ). You are right. Sorry I didn't notice that. :( > > > > We can set_speed to a very small value to avoid disturbing other > > network services, that's good. However using the same value to > > estimate "when to stop" seems odd, since this value can be far away > > from the real network speed (when we are transfering the last bits in > > precopy, we should be using the max network speed all the time, which > > actually is not affected by the threshold value). > > > > IMHO, it'll be clearer if these are two different tunables, e.g., not > > sure whether it'll be cool to add another tunable "set_speed_max", to > > configure the speed for the (2) case (when vm is stopped on source). > > If so, it'll be clearer, and also bring another benefit: users can > > have full control of the last migration phase as well, in case they > > don't want to suffer from a network fluctuation for each ends of > > migration. > > > > Still haven't thought further. Just throw this question out. > > I don't think people are very good at setting the two tunables we already > have! Then I think current tunables are good enough at least to me. And only to control the last bit transfer seems not essential to introduce another one. Thanks! -- peterx