From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Juan Quintela <quintela@redhat.com>, Peter Xu <peterx@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
Richard Henderson <richard.henderson@linaro.org>
Subject: Re: Migration tests are very slow in the CI
Date: Mon, 8 Aug 2022 13:14:13 +0100 [thread overview]
Message-ID: <YvD+FXVf//5xvlgy@redhat.com> (raw)
In-Reply-To: <7bf333f0-7bdc-1ba7-2a45-ffa2894ad809@redhat.com>
On Mon, Aug 08, 2022 at 01:57:17PM +0200, Thomas Huth wrote:
>
> Hi!
>
> Seems like we're getting more timeouts in the CI pipelines since commit
> 2649a72555e ("Allow test to run without uffd") enabled the migration tests
> in more scenarios.
>
> For example:
>
> https://gitlab.com/qemu-project/qemu/-/jobs/2821578332#L49
>
> You can see that the migration-test ran for more than 20 minutes for each
> target (x86 and aarch64)! I think that's way too much by default.
Definitely too much.
> I had a check whether there is one subtest taking a lot of time, but it
> rather seems like each of the migration test is taking 40 to 50 seconds in
> the CI:
>
> https://gitlab.com/thuth/qemu/-/jobs/2825365836#L44
Normally with CI we expect a constant slowdown factor, eg x2.
I expect with migration though, we're triggering behaviour whereby
the guest workload is generating dirty pages quicker than we can
migrate them over localhost. The balance in this can quickly tip
to create an exponential slowdown.
> Given the fact that we're running more than 30 migration tests, this quickly
> sums up to 20 minutes and more.
>
> Could we maybe focus on running only the most important migration tests in
> quick mode, and only run the full suite under an "if (g_test_slow())"
> statement?
THe GitLab shared runners in particular i think are going to impact the
migration tests, given that the runners are overcommitted, pre-emptiable
instances.
If we want reliability we may need to restrict it to just do migration
qtests on the private runners, since we have predictable compute
resource available on those.
I'm not sure if 'g_test_slow' gives us enough granularity though, as
if we enable that, it'll impact the whole test suite, not just
migration tests.
Not sure of the best answer here for how to toggle it.
With 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 :|
next prev parent reply other threads:[~2022-08-08 12:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-08 11:57 Migration tests are very slow in the CI Thomas Huth
2022-08-08 12:14 ` Daniel P. Berrangé [this message]
2022-08-08 12:43 ` Thomas Huth
2022-08-08 12:58 ` Daniel P. Berrangé
2022-08-08 17:00 ` Dr. David Alan Gilbert
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=YvD+FXVf//5xvlgy@redhat.com \
--to=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=richard.henderson@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).