From: Andrey Korolyov <andrey@xdel.ru>
To: Paolo Bonzini <pbonzini@redhat.com>, kvm@vger.kernel.org
Subject: Re: QEMU P2P migration speed
Date: Thu, 06 Feb 2014 17:40:50 +0400 [thread overview]
Message-ID: <52F390E2.5070100@xdel.ru> (raw)
In-Reply-To: <52F25589.50503@redhat.com>
On 02/05/2014 07:15 PM, Paolo Bonzini wrote:
> Il 05/02/2014 11:46, Andrey Korolyov ha scritto:
>> On 02/05/2014 11:27 AM, Paolo Bonzini wrote:
>>> Il 04/02/2014 18:06, Andrey Korolyov ha scritto:
>>>> Migration time is almost independent of VM RSS(varies by ten percent at
>>>> maximum), for situation when VM is active on target host, time is about
>>>> 85 seconds to migrate 8G between hosts, and when it is turned off,
>>>> migration time *increasing* to 120s. For curious ones, frequency
>>>> management is completely inactive on both nodes, neither CStates
>>>> mechanism. Interconnection is relatively fast (20+Gbit/s by IPoIB).
>>>
>>> What version of QEMU?
>>>
>>> Paolo
>>
>> Ancie.. ehm, stable - 1.1.2 from wheezy. Should I try 1.6/1.7?
>
> Yeah, you can checkout the release notes on wiki.qemu.org to find out
> which versions had good improvements. You can also try compiling
> straight from git, there are more speedups there.
>
> Paolo
>
Took and build 1.6.2 and faced a problem - after a couple of bounce
iterations of migration (1->2->1->2) VM is not able to migrate anymore
back in a probabilistic manner with an error 'internal error unexpected
migration status in setup'. Error may disappear over a time, or may not
disappear at all and it may took a lot of tries in a row to succeed.
There are no obvious hints with default logging level in libvirt/qemu
logs and seemingly libvirt is not a cause because "accumulated error
state" preserves over service restarts. Also every VM is affected, not
ones which are experiencing multiple migration actions. Error happens on
3rd-5th second of the migration procedure, if it may help.
What is more interesting, the original counter-intuitive behavior is not
disappeared but increased relative span: 25 vs 70 seconds for fully
commited 8G VM. I am suspecting some mechanism falling back to the idle
and dropping overall performance therefore but can not image one beyond
standard freq/cstates which are definitely turned off.
next prev parent reply other threads:[~2014-02-06 13:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-04 17:06 QEMU P2P migration speed Andrey Korolyov
2014-02-05 7:27 ` Paolo Bonzini
2014-02-05 10:46 ` Andrey Korolyov
2014-02-05 15:15 ` Paolo Bonzini
2014-02-06 13:40 ` Andrey Korolyov [this message]
2014-02-07 8:14 ` Paolo Bonzini
2014-02-07 13:07 ` Andrey Korolyov
2014-02-07 15:26 ` Paolo Bonzini
2014-02-07 15:32 ` Paolo Bonzini
2014-02-07 16:10 ` Michael Tokarev
2014-02-08 11:33 ` Andrey Korolyov
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=52F390E2.5070100@xdel.ru \
--to=andrey@xdel.ru \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.