qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>,
	qemu-devel@nongnu.org, "Peter Xu" <peterx@redhat.com>,
	"Juan Quintela" <quintela@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	 Leonardo Bras <leobras@redhat.com>
Subject: Re: [PATCH v4 00/10] tests/qtest: make migration-test massively faster
Date: Mon, 3 Jul 2023 18:37:14 +0200	[thread overview]
Message-ID: <ae60befe-5d36-eb8b-eaae-bd3ec6722b00@redhat.com> (raw)
In-Reply-To: <20230601161347.1803440-1-berrange@redhat.com>

On 01/06/2023 18.13, Daniel P. Berrangé wrote:
> This makes migration-test faster by observing that most of the pre-copy
> tests don't need to be doing a live migration. They get sufficient code
> coverage with the guest CPUs paused.
> 
> On my machine this cuts the overall execution time of migration-test
> from 13 minutes, down to 8 minutes, without sacrificing any noticeable
> code coverage.
> 
> Of the tests which do still run in live mode, some need to guarantee
> a certain number of iterions. This is achieved by running the 1
> iteration with an incredibly small bandwidth and max downtime to
> prevent convergance, and watching query-migrate for the reported
> iteration to increment. This guarantees that all the tests take at
> least 30 seconds to run per iteration required.
> 
> Watching for the iteration counter to flip is inefficient and not
> actually needed, except on the final iteration before starting
> convergance. On this final iteration we merely need to prove that
> some amount of already transferred data has been made dirty again.
> This in turn will guarantee that a further iteration is required
> beyond the current one. This proof is easy to achieve by monitoring
> the values at two distinct addresses in guest RAM, and can cut the
> 30 second duration down to 1 second for one of the iterations.
> 
> After this this second optimization the runtime is reduced from
> 8 minutes, down to 1 minute 40 seconds, which is pretty decent given
> the amount of coverage we're getting.

It's now ~1 week until the soft freeze, and the migration test still run for 
~8 minutes. This is still quite annoying. Could we please get one of the 
solutions merged before the soft freeze, either Daniel's or Peter's ?

  Thanks,
   Thomas



      parent reply	other threads:[~2023-07-03 16:37 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-01 16:13 [PATCH v4 00/10] tests/qtest: make migration-test massively faster Daniel P. Berrangé
2023-06-01 16:13 ` [PATCH v4 01/10] tests/qtest: add various qtest_qmp_assert_success() variants Daniel P. Berrangé
2023-06-01 22:44   ` Juan Quintela
2023-06-01 16:13 ` [PATCH v4 02/10] tests/qtest: add support for callback to receive QMP events Daniel P. Berrangé
2023-06-01 22:45   ` Juan Quintela
2023-06-02  7:51   ` Thomas Huth
2023-06-01 16:13 ` [PATCH v4 03/10] tests/qtest: get rid of 'qmp_command' helper in migration test Daniel P. Berrangé
2023-06-02  7:52   ` Thomas Huth
2023-06-01 16:13 ` [PATCH v4 04/10] tests/qtest: get rid of some 'qtest_qmp' usage " Daniel P. Berrangé
2023-06-01 16:13 ` [PATCH v4 05/10] tests/qtest: switch to using event callbacks for STOP event Daniel P. Berrangé
2023-06-01 16:13 ` [PATCH v4 06/10] tests/qtest: replace wait_command() with qtest_qmp_assert_success Daniel P. Berrangé
2023-06-01 16:13 ` [PATCH v4 07/10] tests/qtest: capture RESUME events during migration Daniel P. Berrangé
2023-06-02  7:45   ` Juan Quintela
2023-06-01 16:13 ` [PATCH v4 08/10] tests/qtest: distinguish src/dst migration VM stop/resume events Daniel P. Berrangé
2023-06-01 22:47   ` Juan Quintela
2023-06-01 16:13 ` [PATCH v4 09/10] tests/qtest: make more migration pre-copy scenarios run non-live Daniel P. Berrangé
2023-06-01 22:50   ` Juan Quintela
2023-06-01 16:13 ` [PATCH v4 10/10] tests/qtest: massively speed up migration-test Daniel P. Berrangé
2023-06-01 17:29 ` [PATCH] qtest/migration: Document live=true cases Peter Xu
2023-06-01 18:22   ` Daniel P. Berrangé
2023-06-01 22:52   ` Juan Quintela
2023-07-03 16:37 ` Thomas Huth [this message]

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=ae60befe-5d36-eb8b-eaae-bd3ec6722b00@redhat.com \
    --to=thuth@redhat.com \
    --cc=berrange@redhat.com \
    --cc=leobras@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@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).