On 11/21/2017 03:48 PM, Eric Blake wrote:
On 11/21/2017 03:21 PM, Richard W.M. Jones wrote:
> This works OK on x86_64, but fails on our fast new Amberwing (aarch64)
> machine. I've attached the test-suite.log file, but I'm not very sure
> what's going wrong from that.
>
I'll see what I can spot...
Hmm - I wonder - could it be extra delay induced by the flush that
happens to make the write delay longer than the read? Should I swap the
commands (have read be 2 seconds, write be 1 second, so that any
flushing tied to the write is more likely to still finish before the read)?
That should read:
If we write the test do use
file ... rdelay=1 wdelay=2
coupled with
qemu-io -c 'aio_write ...' -c 'aio_read ...'
instead of the current
file ... rdelay=2 wdelay=1
qemu-io -c 'aio_read ...' -c 'aio_write ...'
then the read (which probably does not have to flush) is more likely to
complete quickly than the write, but only if the read gets issued in
parallel.
Want me to submit a patch along those lines?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org