From: Umesh Deshpande <udeshpan@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: pbonzini@redhat.com, mtosatti@redhat.com, qemu-devel@nongnu.org,
kvm@vger.kernel.org, quintela@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH v5 0/4] Separate thread for VM migration
Date: Thu, 25 Aug 2011 02:29:03 -0400 [thread overview]
Message-ID: <4E55EBAF.1000409@redhat.com> (raw)
In-Reply-To: <4E55328A.8000203@codemonkey.ws>
Jitterd Test
I ran jitterd in a migrating VM of size 8GB with and w/o the patch series.
./jitterd -f -m 1 -p 100 -r 40
That is to report the jitter of greater than 400ms during the interval
of 40 seconds.
Jitter in ms. with the migration thread.
Run Total (Peak)
1 No chatter
2 No chatter
3 No chatter
4 409 (360)
Jitter in ms. without migration thread.
Run Total (Peak)
1 4663 (2413)
2 643 (423)
3 1973 (1817)
4 3908 (3772)
--------------------------------------------------------------
Flood ping test : ping to the migrating VM from a third machine (data
over 3 runs)
Latency (ms) ping to a non-migrating VM : Avg 0.156, Max: 0.96
Latency (ms) with migration thread : Avg 0.215, Max: 280
Latency (ms) without migration thread : Avg 6.47, Max: 4562
- Umesh
On 08/24/2011 01:19 PM, Anthony Liguori wrote:
> On 08/23/2011 10:12 PM, Umesh Deshpande wrote:
>> Following patch series deals with VCPU and iothread starvation during
>> the
>> migration of a guest. Currently the iothread is responsible for
>> performing the
>> guest migration. It holds qemu_mutex during the migration and doesn't
>> allow VCPU
>> to enter the qemu mode and delays its return to the guest. The guest
>> migration,
>> executed as an iohandler also delays the execution of other iohandlers.
>> In the following patch series,
>
> Can you please include detailed performance data with and without this
> series?
>
> Perhaps runs of migration with jitterd running in the guest.
>
> Regards,
>
> Anthony Liguori
>
>>
>> The migration has been moved to a separate thread to
>> reduce the qemu_mutex contention and iohandler starvation.
>>
>> Umesh Deshpande (4):
>> MRU ram block list
>> migration thread mutex
>> separate migration bitmap
>> separate migration thread
>>
>> arch_init.c | 38 ++++++++++++----
>> buffered_file.c | 75 +++++++++++++++++--------------
>> cpu-all.h | 42 +++++++++++++++++
>> exec.c | 97 ++++++++++++++++++++++++++++++++++++++--
>> migration.c | 122
>> +++++++++++++++++++++++++++++---------------------
>> migration.h | 9 ++++
>> qemu-common.h | 2 +
>> qemu-thread-posix.c | 10 ++++
>> qemu-thread.h | 1 +
>> savevm.c | 5 --
>> 10 files changed, 297 insertions(+), 104 deletions(-)
>>
>
next prev parent reply other threads:[~2011-08-25 6:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-24 3:12 [Qemu-devel] [RFC PATCH v5 0/4] Separate thread for VM migration Umesh Deshpande
2011-08-24 3:12 ` [Qemu-devel] [RFC PATCH v5 1/4] MRU ram list Umesh Deshpande
2011-08-24 3:12 ` [Qemu-devel] [RFC PATCH v5 2/4] Migration thread mutex Umesh Deshpande
2011-08-26 17:00 ` Marcelo Tosatti
2011-08-24 3:12 ` [Qemu-devel] [RFC PATCH v5 3/4] Separate migration bitmap Umesh Deshpande
2011-08-24 3:12 ` [Qemu-devel] [RFC PATCH v5 4/4] Separate thread for VM migration Umesh Deshpande
2011-08-24 17:19 ` [Qemu-devel] [RFC PATCH v5 0/4] " Anthony Liguori
2011-08-25 6:25 ` Umesh Deshpande
2011-08-25 6:29 ` Umesh Deshpande [this message]
2011-08-25 6:35 ` Avi Kivity
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=4E55EBAF.1000409@redhat.com \
--to=udeshpan@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=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).