From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=46654 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PNedl-00083G-O7
	for qemu-devel@nongnu.org; Tue, 30 Nov 2010 23:50:24 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1PNQZ6-0001SN-0r
	for qemu-devel@nongnu.org; Tue, 30 Nov 2010 08:48:17 -0500
Received: from mail-qy0-f180.google.com ([209.85.216.180]:42372)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1PNQZ5-0000zn-UM
	for qemu-devel@nongnu.org; Tue, 30 Nov 2010 08:48:15 -0500
Received: by qyk29 with SMTP id 29so6527947qyk.4
	for <qemu-devel@nongnu.org>; Tue, 30 Nov 2010 05:48:06 -0800 (PST)
Message-ID: <4CF5008F.2090306@codemonkey.ws>
Date: Tue, 30 Nov 2010 07:47:59 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <cover.1290552026.git.quintela@redhat.com>	<9b23b9b4cee242591bdb356c838a9cfb9af033c1.1290552026.git.quintela@redhat.com>
	<4CF45D67.5010906@codemonkey.ws> <4CF4A478.8080209@redhat.com>
In-Reply-To: <4CF4A478.8080209@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH 09/10] Exit loop if we have been there too
	long
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Juan Quintela <quintela@trasno.org>, qemu-devel@nongnu.org, kvm-devel <kvm@vger.kernel.org>, Juan Quintela <quintela@redhat.com>

On 11/30/2010 01:15 AM, Paolo Bonzini wrote:
> On 11/30/2010 03:11 AM, Anthony Liguori wrote:
>>
>> BufferedFile should hit the qemu_file_rate_limit check when the socket
>> buffer gets filled up.
>
> The problem is that the file rate limit is not hit because work is 
> done elsewhere.  The rate can limit the bandwidth used and makes QEMU 
> aware that socket operations may block (because that's what the 
> buffered file freeze/unfreeze logic does); but it cannot be used to 
> limit the _time_ spent in the migration code.

Yes, it can, if you set the rate limit sufficiently low.

The caveats are 1) the kvm.ko interface for dirty bits doesn't scale for 
large memory guests so we spend a lot more CPU time walking it than we 
should 2) zero pages cause us to burn a lot more CPU time than we 
otherwise would because compressing them is so effective.

In the short term, fixing (2) by accounting zero pages as full sized 
pages should "fix" the problem.

In the long term, we need a new dirty bit interface from kvm.ko that 
uses a multi-level table.  That should dramatically improve scan 
performance.  We also need to implement live migration in a separate 
thread that doesn't carry qemu_mutex while it runs.

Regards,

Anthony Liguori

> Paolo