From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56454 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PnGFW-0002Vs-3Y for qemu-devel@nongnu.org; Wed, 09 Feb 2011 15:02:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PnGFU-0004Zc-55 for qemu-devel@nongnu.org; Wed, 09 Feb 2011 15:02:49 -0500 Received: from mail-fx0-f45.google.com ([209.85.161.45]:57397) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PnGFT-0004ZR-Vc for qemu-devel@nongnu.org; Wed, 09 Feb 2011 15:02:48 -0500 Received: by fxm12 with SMTP id 12so593725fxm.4 for ; Wed, 09 Feb 2011 12:02:47 -0800 (PST) Message-ID: <4D52F2DE.8070103@codemonkey.ws> Date: Wed, 09 Feb 2011 21:02:38 +0100 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Migration speed throttling, max_throttle in migration.c References: <4D52D95D.3030300@scripty.at> In-Reply-To: <4D52D95D.3030300@scripty.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Treutner Cc: qemu-devel@nongnu.org On 02/09/2011 07:13 PM, Thomas Treutner wrote: > Hi, > > I was reading qemu's (qemu-kvm-0.13.0's, to be specific) live > migration code to unterstand how the iterative dirty page transfer is > implemented. During this I noticed that ram_save_live in arch_init.c > is called quite often, more often than I expected (approx. 200 times > for an idle 500MiB VM). I found out that this is because of while > (!qemu_file_rate_limit(f)), which evaluates very often to true, and as > there are remaining dirty pages, ram_save_live is called again. > > As I had set no bandwith limit in the libvirt call, I digged deeper > and found a hard coded maximum bandwidth in migration.c: > > /* Migration speed throttling */ > static uint32_t max_throttle = (32 << 20); > > Using a packet sniffer I verified that max_throttle is Byte/s, here of > course 32 MiB/s. Additionally, it translates directly to network > bandwidth - I was not sure about that, as the bandwidth measured in > ram_save_live seems to be buffer/memory subsystem bandwidth? Because that was roughly how fast my laptop's hard drive was and we had a very bad implementation of migration to file and the limit was the only way to avoid pausing the guest. The reason it's still this today is mainly historic. I've thought about making the default limit unlimited. I'm not sure if anyone has strong opinions. Regards, Anthony Liguori