Re: [Qemu-devel] qom-test on netbsd can be very slow

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Apr 09, 2018 at 06:10:43PM +0100, Peter Maydell wrote:
> My NetBSD build system recently seems to have taken a nosedive
> in how long it takes to finish "make check". This seems to be
> because qom-test (and probably other things where the test interacts
> with the QEMU process) can run very slowly.
> 
> netbsdvm# for i in 1 2 3 4 5 6 7 8 9 10; do
> (QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 time
> tests/qom-test -p /x86_64/qom/pc-i440fx-2.0); done
> /x86_64/qom/pc-i440fx-2.0: OK
>         8.49 real         1.18 user         7.34 sys
> /x86_64/qom/pc-i440fx-2.0: OK
>        10.41 real         1.32 user         9.09 sys
> /x86_64/qom/pc-i440fx-2.0: OK
>         8.45 real         1.24 user         7.24 sys
> /x86_64/qom/pc-i440fx-2.0: OK
>         9.88 real         1.10 user         8.31 sys
> /x86_64/qom/pc-i440fx-2.0: OK
>        11.60 real         1.47 user         9.90 sys
> /x86_64/qom/pc-i440fx-2.0: OK
>        10.94 real         1.28 user         9.68 sys
> /x86_64/qom/pc-i440fx-2.0: OK
>        10.06 real         1.32 user         8.76 sys
> /x86_64/qom/pc-i440fx-2.0: OK
>        13.38 real         1.37 user        12.04 sys
> /x86_64/qom/pc-i440fx-2.0: OK
>        16.19 real         1.46 user        14.29 sys
> /x86_64/qom/pc-i440fx-2.0: OK
>         9.70 real         1.17 user         8.51 sys
> 
> Admittedly this is running in a (KVM) VM, but still, there seems
> something wrong with how long each of these is taking. On Linux
> each run is less than a second, so there's an order-of-magnitude
> slowdown here. Further, I've occasionally seen a run take 100 seconds!
> 
> Does anybody else see this, and any ideas why it might be running slow?

My only real suggestion is to try "git bisect" as presumably this is
a regression caused by something we've merged in this dev cycle ?

> One thing I noticed looking at ktrace output is that we do
> all our reading of QMP input and output with a read syscall
> per character. I don't think that's the cause of this slowness,
> though.

IIRC, that has been long standing behaviour so would be unlikely to
explain a recent slowdown, nor the huge variation in time for some
runs.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|