From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: Thomas Huth <thuth@redhat.com>, Fabiano Rosas <farosas@suse.de>,
Laurent Vivier <lvivier@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [PATCH] tests/qtest: Increase the timeout of the device-introspect-test
Date: Mon, 26 Oct 2026 16:00:17 +0000 [thread overview]
Message-ID: <at95EXMAwxM8soAK@redhat.com> (raw)
In-Reply-To: <87y0bk4hf5.fsf@draig.linaro.org>
On Mon, Oct 26, 2026 at 03:20:46PM +0000, Alex Bennée wrote:
> Thomas Huth <thuth@redhat.com> writes:
>
> > On 26/10/2026 12.04, Alex Bennée wrote:
> >> Thomas Huth <thuth@redhat.com> writes:
> >>
> >>> I'm occasionally seeing timeouts of the device-introspect-test for
> >>> the aarch64 target when running "make check SPEED=thorough" - looks
> >>> like the 720 seconds aren't enough anymore nowadays. Add 2 more
> >>> minutes to give some more headroom.
> >> What is taking so long, I can run all the introspect builds in under
> >> 10
> >> seconds:
> >> ➜ time ./run meson test --suite qtest "*device-introspect*"
> >
> > You've got to run the tests in slow/thorough mode:
> >
> > G_TEST_SLOW=1 time ./run meson test --suite qtest "*device-introspect*"
> >
> > otherwise a lot of the tests will be skipped and the tests will finish
> > fast.
>
> env G_TEST_SLOW=1 QTEST_QEMU_BINARY=./qemu-system-aarch64 ./run time strace -e trace=read,write,recvfrom,sendto -c /home/alex/lsrc/qemu.git/builds/testing/tests/qtest/device-introspect-test --tap -k
> ...
> # slow test /aarch64/device/introspect/concrete/nodefaults/raspi0 executed in 30.19 secs
> # End of nodefaults tests
> # End of concrete tests
> # End of introspect tests
> # End of device tests
> # End of aarch64 tests
> % time seconds usecs/call calls errors syscall
> ------ ----------- ----------- --------- --------- ----------------
> 99.61 793.101303 1 420646079 recvfrom
> 0.28 2.229951 3 619529 sendto
> 0.11 0.840259 4 179705 write
> 0.00 0.000000 0 14 read
> ------ ----------- ----------- --------- --------- ----------------
> 100.00 796.171513 1 421445327 total
> 926.31user 3944.47system 1:28:16elapsed 91%CPU (0avgtext+0avgdata 1132064maxresident)k
> 43824inputs+0outputs (324major+7978563minor)pagefaults 0swaps
>
> So it looks like the majority of the runtime is just ploughing through
> 420M unix socket calls introspecting the same large set of non user
> creatable devices for every machine type. This will just get bigger and
> bigger every new device or machine we add.
NB, you use G_TEST_SLOW so it iterates over all machines, the
default behaviour is just to test 'none' machine only, but....
...urgh, our JSON client parser reads data off the wire 1 byte
at a time....
recvfrom(6, "{", 1, 0, NULL, NULL) = 1
recvfrom(6, "\"", 1, 0, NULL, NULL) = 1
recvfrom(6, "Q", 1, 0, NULL, NULL) = 1
recvfrom(6, "M", 1, 0, NULL, NULL) = 1
recvfrom(6, "P", 1, 0, NULL, NULL) = 1
recvfrom(6, "\"", 1, 0, NULL, NULL) = 1
recvfrom(6, ":", 1, 0, NULL, NULL) = 1
recvfrom(6, " ", 1, 0, NULL, NULL) = 1
recvfrom(6, "{", 1, 0, NULL, NULL) = 1
recvfrom(6, "\"", 1, 0, NULL, NULL) = 1
recvfrom(6, "v", 1, 0, NULL, NULL) = 1
recvfrom(6, "e", 1, 0, NULL, NULL) = 1
recvfrom(6, "r", 1, 0, NULL, NULL) = 1
recvfrom(6, "s", 1, 0, NULL, NULL) = 1
recvfrom(6, "i", 1, 0, NULL, NULL) = 1
recvfrom(6, "o", 1, 0, NULL, NULL) = 1
recvfrom(6, "n", 1, 0, NULL, NULL) = 1
recvfrom(6, "\"", 1, 0, NULL, NULL) = 1
recvfrom(6, ":", 1, 0, NULL, NULL) = 1
recvfrom(6, " ", 1, 0, NULL, NULL) = 1
recvfrom(6, "{", 1, 0, NULL, NULL) = 1
recvfrom(6, "\"", 1, 0, NULL, NULL) = 1
recvfrom(6, "q", 1, 0, NULL, NULL) = 1
recvfrom(6, "e", 1, 0, NULL, NULL) = 1
recvfrom(6, "m", 1, 0, NULL, NULL) = 1
recvfrom(6, "u", 1, 0, NULL, NULL) = 1
recvfrom(6, "\"", 1, 0, NULL, NULL) = 1
recvfrom(6, ":", 1, 0, NULL, NULL) = 1
recvfrom(6, " ", 1, 0, NULL, NULL) = 1
recvfrom(6, "{", 1, 0, NULL, NULL) = 1
recvfrom(6, "\"", 1, 0, NULL, NULL) = 1
recvfrom(6, "m", 1, 0, NULL, NULL) = 1
recvfrom(6, "i", 1, 0, NULL, NULL) = 1
recvfrom(6, "c", 1, 0, NULL, NULL) = 1
recvfrom(6, "r", 1, 0, NULL, NULL) = 1
recvfrom(6, "o", 1, 0, NULL, NULL) = 1
recvfrom(6, "\"", 1, 0, NULL, NULL) = 1
recvfrom(6, ":", 1, 0, NULL, NULL) = 1
> I think we need to reconsider exactly what it is we are trying to test
> here.
I fear this test suite is perhaps just exposing a scalability problem
of our JSON parser. I wonder how much quicker could it be if it read
data in chunks ....
With regards,
Daniel
--
|: https://berrange.com ~~ https://hachyderm.io/@berrange :|
|: https://libvirt.org ~~ https://entangle-photo.org :|
|: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
next prev parent reply other threads:[~2026-10-26 16:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 9:23 [PATCH] tests/qtest: Increase the timeout of the device-introspect-test Thomas Huth
2026-10-26 11:04 ` Alex Bennée
2026-10-26 11:30 ` Thomas Huth
2026-10-26 13:35 ` Alex Bennée
2026-10-26 15:20 ` Alex Bennée
2026-10-26 16:00 ` Daniel P. Berrangé [this message]
2026-10-26 16:18 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=at95EXMAwxM8soAK@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=farosas@suse.de \
--cc=lvivier@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.