From: Paolo Bonzini <pbonzini@redhat.com>
To: Umesh Deshpande <udeshpan@redhat.com>
Cc: mtosatti@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org,
Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] [RFC PATCH v2 1/3] separate thread for VM migration
Date: Mon, 01 Aug 2011 11:37:39 +0200 [thread overview]
Message-ID: <4E3673E3.1000201@redhat.com> (raw)
In-Reply-To: <e5a28f3e3d8ff3c5c08b307ef320051632832718.1311971938.git.udeshpan@redhat.com>
On 07/29/2011 10:57 PM, Umesh Deshpande wrote:
> This patch creates a separate thread for the guest migration on the source side.
>
> Signed-off-by: Umesh Deshpande<udeshpan@redhat.com>
Looks pretty good!
One thing that shows, is that the interface separation between
buffered_file.c is migration.c is pretty weird. Your patch makes it
somewhat worse, but it was like this before so it's not your fault. The
good thing is that if buffered_file.c uses threads, you can fix a large
part of this and get even simpler code:
1) there is really just one way to implement migrate_fd_put_notify, and
with your simplifications it does not belong anymore in migration.c.
2) s->callback is actually not NULL exactly if s->file->frozen_output is
true, you can remove it as well;
3) buffered_close is messy because it can be called from both the
iothread (monitor->migrate_fd_cancel->migrate_fd_cleanup->qemu_fclose)
or the migration thread (after qemu_savevm_state_complete). But
buffered_close is actually very similar to your thread function (it does
flush+wait_for_unfreeze, basically)! So buffered_close can be simply:
s->closed = 1;
ret = qemu_thread_join(s->thread); /* doesn't exist yet :) */
qemu_free(...);
return ret;
Another nit is that here:
> + if (migrate_fd_check_expire()) {
> + buffered_rate_tick(s->file);
> + }
> +
> + if (s->state != MIG_STATE_ACTIVE) {
> + break;
> + }
> +
> + if (s->callback) {
> + migrate_fd_wait_for_unfreeze(s);
> + s->callback(s);
> + }
you can still have a busy wait.
Putting it all together, you can move the thread function back to
buffered_file.c like:
while (!s->closed || (!s->has_error && s->buffer_size)) {
if (s->freeze_output) {
qemu_mutex_unlock_iothread();
s->wait_for_unfreeze(s);
qemu_mutex_lock_iothread();
/* This comes from qemu_file_put_notify (via
buffered_put_buffer---can be simplified a lot too?).
s->freeze_output = 0;
/* Test again for cancellation. */
continue;
}
int64_t current_time = qemu_get_clock_ms(rt_clock);
if (s->expire_time > current_time) {
struct timeval tv = { .tv_sec = 0, .tv_usec = ... };
qemu_mutex_unlock_iothread();
select (0, NULL, NULL, NULL, &tv);
qemu_mutex_lock_iothread();
s->expire_time = qemu_get_clock_ms(rt_clock) + 100;
continue;
}
/* This comes from buffered_rate_tick. */
s->bytes_xfer = 0;
buffered_flush(s);
if (!s->closed) {
s->put_ready(s->opaque);
}
}
ret = s->close(s->opaque);
...
Does it look sane?
Paolo
next prev parent reply other threads:[~2011-08-01 9:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-29 20:57 [Qemu-devel] [RFC PATCH v2 0/3] separate thread for VM migration Umesh Deshpande
2011-07-29 20:57 ` [Qemu-devel] [RFC PATCH v2 1/3] " Umesh Deshpande
2011-08-01 9:37 ` Paolo Bonzini [this message]
2011-08-01 21:00 ` Umesh Deshpande
2011-08-02 7:44 ` Paolo Bonzini
2011-07-29 20:57 ` [Qemu-devel] [RFC PATCH v2 2/3] fine grained qemu_mutex locking for migration Umesh Deshpande
2011-08-01 9:39 ` Paolo Bonzini
2011-08-02 16:30 ` Marcelo Tosatti
2011-07-29 20:57 ` [Qemu-devel] [RFC PATCH v2 3/3] Per memslot dirty bitmap Umesh Deshpande
2011-08-02 16:29 ` Marcelo Tosatti
2011-08-01 9:41 ` [Qemu-devel] [RFC PATCH v2 0/3] separate thread for VM migration shawn che
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=4E3673E3.1000201@redhat.com \
--to=pbonzini@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=udeshpan@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).