Libguestfs - Nov 2017 - Re: [Qemu-devel] Effect of qemu-img convert -m and -W options

On Thu, Nov 16, 2017 at 02:47:46PM +0000, Stefan Hajnoczi
wrote:
> The threads you observed are the thread pool that performs
> preadv(2)/pwritev(2) syscalls.  The Linux AIO API could be used instead
> and does not use threads for read and write operations.
I guess if I used AIO then I wouldn't get any parallelism at all since
Linux doesn't block on local file access (at least, it never used to)?
> Interesting.  Did you perform multiple runs of each setting to verify
> that the benchmark results are stable with little volatility?
I retested the -m 8 no-W/-W ones because those were so unexpected and
those are repeatable.
> Which command-line did you use to create the preallocated qcow2 file?
What I actually did was qemu-img convert -n into the existing qcow2
file, so there was no separate command for that.
> Are the source and target files on the same file system and host block
> device?  The benefit of using multiple coroutines depends on the
> performance characteristics of the source and target files.
Both local filesystems, but on different SATA devices.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

On Thu, Nov 16, 2017 at 3:10 PM, Richard W.M. Jones <rjones@redhat.com>
wrote:
> On Thu, Nov 16, 2017 at 02:47:46PM +0000, Stefan Hajnoczi wrote:
>> The threads you observed are the thread pool that performs
>> preadv(2)/pwritev(2) syscalls.  The Linux AIO API could be used instead
>> and does not use threads for read and write operations.
>
> I guess if I used AIO then I wouldn't get any parallelism at all since
> Linux doesn't block on local file access (at least, it never used to)?
Even assuming there is enough free page cache, file systems can
definitely block for metadata updates (e.g. space allocation as a file
grows).  I don't think it's possible to assume that pwritev(2)
doesn't
block.
>> Are the source and target files on the same file system and host block
>> device?  The benefit of using multiple coroutines depends on the
>> performance characteristics of the source and target files.
>
> Both local filesystems, but on different SATA devices.
Okay.  I'm curious what the strace -f output looks like (only the
preadv(2)/pwritev(2) syscalls are interesting at the moment).

Stefan

On Thu, Nov 16, 2017 at 05:30:48PM +0000, Stefan Hajnoczi
wrote:
> On Thu, Nov 16, 2017 at 3:10 PM, Richard W.M. Jones
<rjones@redhat.com> wrote:
> > Both local filesystems, but on different SATA devices.
> 
> Okay.  I'm curious what the strace -f output looks like (only the
> preadv(2)/pwritev(2) syscalls are interesting at the moment).
Here's the full strace from one run:

  http://oirase.annexia.org/tmp/strace.xz

The command is (with the output.qcow2 file created in a previous run):

  $ strace -o /tmp/strace -f -s 1024 qemu-img convert -f raw fedora-27.img -O
qcow2 /var/tmp/output.qcow2 -m 8 -W -n

The version of qemu is: qemu-2.10.0-7.fc28.x86_64

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html