From: Anthony Liguori <anthony@codemonkey.ws>
To: Pierre Riteau <Pierre.Riteau@irisa.fr>
Cc: Chris Lalancette <clalance@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [BUG] Regression of exec migration
Date: Thu, 27 Aug 2009 11:24:51 -0500 [thread overview]
Message-ID: <4A96B353.8070600@codemonkey.ws> (raw)
In-Reply-To: <076B9FA6-C362-47C1-AA8B-70BF147843A6@irisa.fr>
Pierre Riteau wrote:
> On 27 août 09, at 16:13, Anthony Liguori wrote:
>
>> Pierre Riteau wrote:
>>> [Sorry Chris, resending without the giant attachments.]
>>>
>>> Commit 907500095851230a480b14bc852c4e49d32cb16d makes exec migration
>>> much slower than before.
>>> I'm running the latest HEAD of qemu, on Debian Lenny 5.0.2.
>>>
>>> I'm migrating a fully booted Linux VM (also running Lenny) with
>>> 128MB of RAM to a file, using the following command: migrate "exec:
>>> cat > vmimage". The resulting file has a size of 57MB (because we
>>> save only what is allocated from the 128MB).
>>> With the current HEAD, it takes from 15 to 40 seconds (it's
>>> variable) to perform the migration to the file.
>>> With commit 907500095851230a480b14bc852c4e49d32cb16d reverted (or
>>> just commenting the "socket_set_nonblock(s->fd);" statement), it
>>> takes about 3 seconds.
>>
>> Without that changeset, it wasn't a live migration. The better way
>> to compare would be to issue stop before doing the migrate and
>> compare that time with the previous time.
>>
>> When a migration is live, it's iterative which means there's more
>> work to do.
>
> I tried with stop too, and I get the same results. It's an idle VM so
> only a small number of pages are being modified while the migration is
> going on.
> I agree that the changeset seems good, the code it replaces was
> obviously wrong.
> But I think there is something wrong somewhere else, unless it is
> considered normal that it takes so much time for an exec migration.
> To compare, using the same setup with one more machine and a Gigabit
> network, a tcp migration capped at 35m (the slowest speed I've
> measured from the disk, it can be way faster) takes about the same
> time, between 2 and 4 seconds.
I don't think the difference between 3 seconds and 15 seconds is
significant.
Can you try a different workload that will result in a migration that
takes much longer (say multiple minutes)? That is, I'd like to know
whether there's a fixed greater cost of exec: migration vs. factor of 5.
I expect exec: to be slower because there is more copying but not by a
factor of 5. I expect that it's going to be a combination of relatively
small constant factor + relatively small constant fixed cost.
Regards,
Anthony Liguori
next prev parent reply other threads:[~2009-08-27 16:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-27 9:19 [Qemu-devel] [BUG] Regression of exec migration Pierre Riteau
2009-08-27 14:13 ` Anthony Liguori
2009-08-27 16:16 ` Pierre Riteau
2009-08-27 16:24 ` Anthony Liguori [this message]
2009-08-28 13:04 ` Pierre Riteau
2009-08-28 15:41 ` Anthony Liguori
2009-08-31 22:55 ` [Qemu-devel] " Charles Duffy
2009-09-01 11:57 ` Pierre Riteau
2009-09-01 20:37 ` Charles Duffy
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=4A96B353.8070600@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=Pierre.Riteau@irisa.fr \
--cc=clalance@redhat.com \
--cc=qemu-devel@nongnu.org \
/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.