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

[Stefan Hajnoczi <stefanha@gmail.com>]

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