From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M78c9-0003OF-O1 for qemu-devel@nongnu.org; Thu, 21 May 2009 09:47:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M78c5-0003NN-12 for qemu-devel@nongnu.org; Thu, 21 May 2009 09:47:17 -0400 Received: from [199.232.76.173] (port=52274 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M78c4-0003NJ-PJ for qemu-devel@nongnu.org; Thu, 21 May 2009 09:47:12 -0400 Received: from mx2.redhat.com ([66.187.237.31]:50412) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M78c4-00065Y-9d for qemu-devel@nongnu.org; Thu, 21 May 2009 09:47:12 -0400 Date: Thu, 21 May 2009 10:52:18 -0300 From: Glauber Costa Subject: Re: [Qemu-devel] [PATCH] augment info migrate with page status Message-ID: <20090521135218.GA24584@poweredge.glommer> References: <1242861605-12844-1-git-send-email-glommer@redhat.com> <4A152B51.2080600@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A152B51.2080600@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dor Laor Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org > > It would be nice to zero pages_transferred each migration operation. Yeah, that makes sense. > ram_save_threshold is really to small. From Uri's past measurements, as > value of 50 is a > better suite. Every value is arbitrary in essence. If after this patches we still see need to change that, I'd say change it to a percentage of guest total memory, or even better, the average number of pages that were transferred per iteration > Alternately it can be parametrized by the monitor command. With this, I completely disagree. Let us say we switch in the future to a new migration algorithm that does not rely on any treshold at all. What should we do with this parameter? This is totally implementation dependant, and should not be exposed. the bandwidth is what we want to control externally. > > In general there is small drawback in the current approach: > The way bandwidth is capped, iirc, in every second you start consuming > migration > bandwidth. If the bandwidth allocation was consumed after 100msec, > you'll wait 900msec. > In this period, mgmt app reading the ram_save_remaining will notice that > migration does > not progress and might either increase bandwidth or stop the guest. So what? If one second is too much, have them to use 500ms. Also, if the bandwidth was consumed after 100 ms and the number of remaining pages _increased_ when mgmt tool read it again, this is the most genuine case of need for increasing bandwidth in the whole universe. Or have them use a better algorithm altogether. The point is, this is not qemu's problem.