qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: qemu-devel@nongnu.org
Cc: quintela@redhat.com
Subject: [Qemu-devel] [PATCH v2 3/4] buffered_file: rate-limit producers based on buffer size
Date: Tue, 20 Nov 2012 17:45:35 +0100	[thread overview]
Message-ID: <1353429936-29180-4-git-send-email-pbonzini@redhat.com> (raw)
In-Reply-To: <1353429936-29180-1-git-send-email-pbonzini@redhat.com>

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 <pbonzini@redhat.com>
---
 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;
-- 
1.7.1

  parent reply	other threads:[~2012-11-20 16:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-20 16:45 [Qemu-devel] [PATCH v2 0/4] migration: fix rate limiting Paolo Bonzini
2012-11-20 16:45 ` [Qemu-devel] [PATCH v2 1/4] buffered_file: reset bytes_xfer on every tick Paolo Bonzini
2012-11-20 16:45 ` [Qemu-devel] [PATCH v2 2/4] buffered_file: do not send more than s->bytes_xfer bytes per tick Paolo Bonzini
2012-11-20 16:45 ` Paolo Bonzini [this message]
2012-11-24 19:53   ` [Qemu-devel] [PATCH v2 3/4] buffered_file: rate-limit producers based on buffer size Blue Swirl
2012-11-26  8:17     ` Paolo Bonzini
2012-11-20 16:45 ` [Qemu-devel] [PATCH v2 4/4] buffered_file: do not automatically unfreeze output on buffered_put_buffer Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1353429936-29180-4-git-send-email-pbonzini@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).