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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs