All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: Avi Kivity <avi@redhat.com>
Cc: KVM list <kvm@vger.kernel.org>
Subject: Re: *terrible* speed of savevm/loadvm/delvm
Date: Thu, 20 Nov 2008 22:08:52 +0300	[thread overview]
Message-ID: <4925B5C4.1030008@msgid.tls.msk.ru> (raw)
In-Reply-To: <491C1E8C.3070701@redhat.com>

Avi Kivity wrote Thu, 13 Nov 2008 14:33:16 +0200:
> Michael Tokarev wrote:
>> Somewhere between kvm-75 and kvm-78, the
>> mentioned commands has been slowed down
>> to insane levels.  By "insane" I mean to
>> take about 10 minutes(!) to save/load a
>> 128MB RAM/1GB HDD VM's state.  It used
>> to require several seconds for much larger
>> VMs...
>>
>> Here's a typical sequence of system calls
>> during savevm:
> [snip strace]
> 
>> As you see, it writes 2 bytes, llseeks to THE SAME
>> position, writes next 2 bytes and so on.  This takes
>> HUGE amount of time, and can be done, in most cases,
>> in a single write without any seeks.
>>
>> Is it just me or are savevm/loadvm/delvm really THAT
>> broken?
> 
> It's qcow2 that is broken, with the new default cache=writethrough. 
> Does cache=writeback speed things up?

Please excuse me for this long delay replying...
I tried other solutions meanwhile (migrate to exec:), but did not
succeed there either.

Well.  While with writeback mode, the speed is definitely
better.  But it is still very very slow - not THAT terrible,
but it still takes several mins to complete a 512MB VM with
a single 4Gb qcow2 file.

> This is probably block reference counts being updated.  There were some
> batching patches posted, but they have not been applied yet, and are
> probably insufficient for savevm.

Oh well.... :(

So it really is that there's no way to "freeze" a vm currently.
savevm/loadvm is too slow to be useful, and migrate does not
work with local files (yet)...

>> And since migration to disk has been removed too,
>> there's no way currently to save the VM state...
> 
> That's being restored.

Thanks!  Tried that (current patches), does not quite here yet :)

/mjt

  reply	other threads:[~2008-11-20 19:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-12 17:15 *terrible* speed of savevm/loadvm/delvm Michael Tokarev
2008-11-13 12:33 ` Avi Kivity
2008-11-20 19:08   ` Michael Tokarev [this message]
2008-11-23 13:51     ` Avi Kivity
2008-11-23 20:08       ` Michael Tokarev

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=4925B5C4.1030008@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.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.