From patchwork Tue Nov 20 16:45:35 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Bonzini X-Patchwork-Id: 200400 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id EAF932C007A for ; Wed, 21 Nov 2012 03:46:26 +1100 (EST) Received: from localhost ([::1]:43355 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Taqxs-00081a-CU for incoming@patchwork.ozlabs.org; Tue, 20 Nov 2012 11:46:24 -0500 Received: from eggs.gnu.org ([208.118.235.92]:46730) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TaqxU-0007ag-Hy for qemu-devel@nongnu.org; Tue, 20 Nov 2012 11:46:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TaqxP-0001dj-QI for qemu-devel@nongnu.org; Tue, 20 Nov 2012 11:46:00 -0500 Received: from mail-ia0-f173.google.com ([209.85.210.173]:41370) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TaqxP-0001df-Le for qemu-devel@nongnu.org; Tue, 20 Nov 2012 11:45:55 -0500 Received: by mail-ia0-f173.google.com with SMTP id w21so3023697iac.4 for ; Tue, 20 Nov 2012 08:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:date:message-id:x-mailer:in-reply-to :references; bh=0KfWre7T2JntGSFuY18xE5Ww7VBFMggzb9VNxRPTVnk=; b=kZbq8Cw16pG25Gx2ro/dG+QlWf9XH2qS7mDe7znvRrwzwhfsIOjjBwePTifwQ9/a0E 4N3DX+JdPrSFX2GyBOc3UxC9hUyetYJ42Wwkk6p5riGjPn0O/yTZHAUyKOHzizbWnbEN adllPYDEZEy9yYUOMuB2ny66a5yRQgRg279Ls5sZ2Wr53/sLMyjJLbfNgeYfFtoHnL4R +sMeqOJph1ZkWMNq6YalXxzl6BRVdYMQH13OXbIZUuOhemf9ltBoAOiE9VmLuE52Z2p2 mxgqVVuLdI2WOxtjUG1CaQtG0lZ27wwwP7GmejnzjFNIymBmGoQ5QU1UvHO97uK2i34h AyZw== Received: by 10.50.0.203 with SMTP id 11mr10731597igg.69.1353429955155; Tue, 20 Nov 2012 08:45:55 -0800 (PST) Received: from yakj.usersys.redhat.com (93-34-169-1.ip50.fastwebnet.it. [93.34.169.1]) by mx.google.com with ESMTPS id x7sm10749320igk.8.2012.11.20.08.45.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Nov 2012 08:45:54 -0800 (PST) From: Paolo Bonzini To: qemu-devel@nongnu.org Date: Tue, 20 Nov 2012 17:45:35 +0100 Message-Id: <1353429936-29180-4-git-send-email-pbonzini@redhat.com> X-Mailer: git-send-email 1.7.12.1 In-Reply-To: <1353429936-29180-1-git-send-email-pbonzini@redhat.com> References: <1353429936-29180-1-git-send-email-pbonzini@redhat.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.210.173 Cc: quintela@redhat.com Subject: [Qemu-devel] [PATCH v2 3/4] buffered_file: rate-limit producers based on buffer size X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org buffered_rate_limit is called to prevent the RAM migration callback from putting too much data in the buffer. So it has to check against the amount of data currently in the buffer, not against the amount of data that has been transferred so far. s->bytes_xfer is used to communicate between successive calls of buffered_put_buffer. Buffered_rate_tick resets it every now and then to prevent moving too much buffered data to the socket at once. However, its value does not matter for the producer of the data. Here is the result for migrating an idle guest with 3GB of memory and ~360MB of non-zero memory: migrate_set_speed Before After ------------------------------------------------------------ default (32MB/sec) ~3 sec ~13 sec infinite (10GB/sec) ~3 sec ~3 sec Note that before this patch, QEMU is transferring of 100 MB/sec despite the rate limiting. Also fix an off-by-one error, where > was used instead of >=. With this fix, the condition in buffered_put_buffer is really the opposite of "rate limit reached", so write it explicitly like that. Signed-off-by: Paolo Bonzini --- buffered_file.c | 7 ++----- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/buffered_file.c b/buffered_file.c index edead5c..2dac99a 100644 --- a/buffered_file.c +++ b/buffered_file.c @@ -125,7 +125,7 @@ static int buffered_put_buffer(void *opaque, const uint8_t *buf, int64_t pos, in if (pos == 0 && size == 0) { DPRINTF("file is ready\n"); - if (!s->freeze_output && s->bytes_xfer < s->xfer_limit) { + if (!qemu_file_rate_limit(s->file)) { DPRINTF("notifying client\n"); migrate_fd_put_ready(s->migration_state); } @@ -190,10 +190,7 @@ static int buffered_rate_limit(void *opaque) if (ret) { return ret; } - if (s->freeze_output) - return 1; - - if (s->bytes_xfer > s->xfer_limit) + if (s->buffer_size >= s->xfer_limit) return 1; return 0;