qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Richard W.M. Jones" <rjones@redhat.com>
To: libguestfs@redhat.com
Cc: qemu-devel@nongnu.org, pl@kamp.de
Subject: [Qemu-devel] Effect of qemu-img convert -m and -W options
Date: Wed, 15 Nov 2017 11:52:46 +0000	[thread overview]
Message-ID: <20171115115246.GA1955@redhat.com> (raw)

[CC to qemu-devel since I'm obviously doing something wrong here,
I'm just not sure what.]

I was getting ready to add multiple threads to ‘qemu-img convert’ (the
longest part of v2v conversions) when I noticed that it had them
already!  (To be fair this was only added in February this year so no
wonder we didn't notice.)

To enable parallel convert we would need to use the ‘qemu-img convert
-W’ option (which allows out-of-order writes to the destination) and
‘qemu-img convert -m <#num-coroutines>’ option to select the
parallelism (defaults to 8).  The documentation refers to coroutines
but I verified from strace that it is using real threads.

I did some testing to see what effect this has.  For this I used a
large guest image which is approximately a third full of random data
(the rest being sparsely allocated):

  Source format:       raw
  Source virtual size: 100 GB
  Source used space:   31 GB  
  Target format:       qcow2
  Version:             qemu-img-2.10.0-7.fc28.x86_64
  Conversion command:
    rm -f /to/target
    time qemu-img convert [-W] [-m ##] -f raw source.img -O qcow2 /to/target

Source and target are regular files on two different disks.  The test
machine is a Xeon E5 with 16 real cores.

----------------------------------------------------------------------
                  Non-preallocated output
                  (times are in seconds)
                   without -W       -W

-m 1                153              -

-m 4                155             157

-m 8 [default]      158             231

-m 16 [max]         166             166
----------------------------------------------------------------------

The documentation for ‘-W’ notes that this is only recommended for
preallocated outputs (which the test above does not use).  So let's
try using a preallocated qcow2 output.

  Conversion command:
    # the same target file is reused each time
    time qemu-img convert -n [-W] [-m ##] -f raw source.img -O qcow2 /to/target

----------------------------------------------------------------------
                   Preallocated output
                  (times are in seconds)
                   without -W       -W

-m 1                147              -

-m 4                146             145

-m 8 [default]      146             199

-m 16 [max]         147             146
----------------------------------------------------------------------

Based on this there seems to be some issue with the ‘-W’ option -- I
even thought I might have it backwards, but checking the code it does
seem like ‘-W’ enables (rather than disables) out of order writes.
Also some bizarre interaction between ‘-W’ and ‘-m 8’.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

             reply	other threads:[~2017-11-15 11:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-15 11:52 Richard W.M. Jones [this message]
2017-11-16 14:47 ` [Qemu-devel] Effect of qemu-img convert -m and -W options Stefan Hajnoczi
2017-11-16 14:51   ` Peter Lieven
2017-11-16 15:12     ` Richard W.M. Jones
2017-11-16 17:20       ` Stefan Hajnoczi
2017-11-16 15:10   ` Richard W.M. Jones
2017-11-16 17:30     ` Stefan Hajnoczi
2017-11-16 18:00       ` Richard W.M. Jones
2017-11-20 15:57         ` Stefan Hajnoczi

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=20171115115246.GA1955@redhat.com \
    --to=rjones@redhat.com \
    --cc=libguestfs@redhat.com \
    --cc=pl@kamp.de \
    --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 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).