All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org,  qemu-block@nongnu.org,
	 Paolo Bonzini <pbonzini@redhat.com>,
	 Thomas Huth <thuth@redhat.com>,  John Snow <jsnow@redhat.com>,
	 Li Zhijian <lizhijian@fujitsu.com>,
	 Stefan Hajnoczi <stefanha@redhat.com>,
	 Zhang Chen <chen.zhang@intel.com>,
	 Laurent Vivier <lvivier@redhat.com>
Subject: Re: [PATCH v2 5/6] tests/qtest: massively speed up migration-tet
Date: Sat, 22 Apr 2023 00:15:34 +0200	[thread overview]
Message-ID: <87bkjgg9vd.fsf@secure.mitica> (raw)
In-Reply-To: <20230421171411.566300-6-berrange@redhat.com> ("Daniel P. Berrangé"'s message of "Fri, 21 Apr 2023 18:14:10 +0100")

Daniel P. Berrangé <berrange@redhat.com> wrote:
> The migration test cases that actually exercise live migration want to
> ensure there is a minimum of two iterations of pre-copy, in order to
> exercise the dirty tracking code.
>
> Historically we've queried the migration status, looking for the
> 'dirty-sync-count' value to increment to track iterations. This was
> not entirely reliable because often all the data would get transferred
> quickly enough that the migration would finish before we wanted it
> to. So we massively dropped the bandwidth and max downtime to
> guarantee non-convergance. This had the unfortunate side effect
> that every migration took at least 30 seconds to run (100 MB of
> dirty pages / 3 MB/sec).
>
> This optimization takes a different approach to ensuring that a
> mimimum of two iterations. Rather than waiting for dirty-sync-count
> to increment, directly look for an indication that the source VM
> has dirtied RAM that has already been transferred.
>
> On the source VM a magic marker is written just after the 3 MB
> offset. The destination VM is now montiored to detect when the
> magic marker is transferred. This gives a guarantee that the
> first 3 MB of memory have been transferred. Now the source VM
> memory is monitored at exactly the 3MB offset until we observe
> a flip in its value. This gives us a guaranteed that the guest
> workload has dirtied a byte that has already been transferred.
>
> Since we're looking at a place that is only 3 MB from the start
> of memory, with the 3 MB/sec bandwidth, this test should complete
> in 1 second, instead of 30 seconds.
>
> Once we've proved there is some dirty memory, migration can be
> set back to full speed for the remainder of the 1st iteration,
> and the entire of the second iteration at which point migration
> should be complete.
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Hi

I think this is not enough.  As said before:
- xbzrle needs 3 iterations
- auto converge needs around 12 iterations (forgot) the exact number,
  but it is a lot.
- for (almost) all the rest of the tests, we don't really care, we just
  need the migration to finish.

One easy way to "test" it is: Change the "meaning" of ZERO downtime to
mean that we don't want to enter the completion stage, just continue
sending data.

Changig this in qemu:

modified   migration/migration.c
@@ -2726,6 +2726,9 @@ static MigIterateState migration_iteration_run(MigrationState *s)
 
     trace_migrate_pending_estimate(pending_size, must_precopy, can_postcopy);
 
+    if (s->threshold_size == 0) {
+        return MIG_ITERATE_RESUME;
+    }
     if (must_precopy <= s->threshold_size) {
         qemu_savevm_state_pending_exact(&must_precopy, &can_postcopy);
         pending_size = must_precopy + can_postcopy;

And just setting the downtime to zero should be enough.

It is too late, so before I start with this, what do you think?

Later, Juan.



  reply	other threads:[~2023-04-21 22:16 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-21 17:14 [PATCH v2 0/6] tests/qtest: make migration-test massively faster Daniel P. Berrangé
2023-04-21 17:14 ` [PATCH v2 1/6] tests/qtest: replace qmp_discard_response with qtest_qmp_assert_success Daniel P. Berrangé
2023-04-21 21:52   ` Juan Quintela
2023-04-23  2:22   ` Zhang, Chen
2023-04-21 17:14 ` [PATCH v2 2/6] tests/qtests: remove migration test iterations config Daniel P. Berrangé
2023-04-21 21:54   ` Juan Quintela
2023-04-26  9:07     ` Daniel P. Berrangé
2023-04-26  9:42       ` Juan Quintela
2023-04-26 10:15         ` Daniel P. Berrangé
2023-04-21 17:14 ` [PATCH v2 3/6] tests/qtest: capture RESUME events during migration Daniel P. Berrangé
2023-04-21 21:59   ` Juan Quintela
2023-04-24  9:53     ` Daniel P. Berrangé
2023-05-26 11:56       ` Daniel P. Berrangé
2023-04-21 17:14 ` [PATCH v2 4/6] tests/qtest: make more migration pre-copy scenarios run non-live Daniel P. Berrangé
2023-04-21 22:06   ` Juan Quintela
2023-04-24 21:01   ` Fabiano Rosas
2023-05-26 17:58     ` Daniel P. Berrangé
2023-05-31 12:15       ` Daniel P. Berrangé
2023-04-21 17:14 ` [PATCH v2 5/6] tests/qtest: massively speed up migration-tet Daniel P. Berrangé
2023-04-21 22:15   ` Juan Quintela [this message]
2023-04-21 17:14 ` [PATCH v2 6/6] tests/migration: Only run auto_converge in slow mode Daniel P. Berrangé
2023-04-23  2:41   ` Zhang, Chen
2023-04-24  5:58     ` Juan Quintela
2023-04-24  6:56       ` Thomas Huth
2023-04-24  8:05         ` Zhang, Chen
2023-04-24  8:06   ` Zhang, Chen

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=87bkjgg9vd.fsf@secure.mitica \
    --to=quintela@redhat.com \
    --cc=berrange@redhat.com \
    --cc=chen.zhang@intel.com \
    --cc=jsnow@redhat.com \
    --cc=lizhijian@fujitsu.com \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --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.