[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] qom-test on netbsd can be very slow
From: |
Daniel P . Berrangé |
Subject: |
Re: [Qemu-devel] qom-test on netbsd can be very slow |
Date: |
Tue, 10 Apr 2018 09:19:21 +0100 |
User-agent: |
Mutt/1.9.2 (2017-12-15) |
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 :|