All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Leonardo Bras <leobras@redhat.com>
Cc: Juan Quintela <quintela@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Peter Xu <peterx@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [RFC PATCH v1 1/1] migration: Disable postcopy + multifd migration
Date: Thu, 30 Mar 2023 15:20:14 +0100	[thread overview]
Message-ID: <ZCWanp5hITk4HImX@redhat.com> (raw)
In-Reply-To: <20230327161518.2385074-1-leobras@redhat.com>

On Mon, Mar 27, 2023 at 01:15:18PM -0300, Leonardo Bras wrote:
> Since the introduction of multifd, it's possible to perform a multifd
> migration and finish it using postcopy.
> 
> A bug introduced by yank (fixed on cfc3bcf373) was previously preventing
> a successful use of this migration scenario, and now it should be
> working on most cases.
> 
> But since there is not enough testing/support nor any reported users for
> this scenario, we should disable this combination before it may cause any
> problems for users.

Clearly we don't have enough testing, but multifd+postcopy looks
like a clearly useful scenario that we should be supporting.

Every post-copy starts with at least one pre-copy iteration, and
using multifd for that will be important for big VMs where single
threaded pre-copy is going to be CPU bound. The greater amount we
can transfer in the pre-copy phase, the less page faults / latency
spikes postcopy is going to see.

In terms of migration usage, my personal recommendation to mgmt
apps would be that they should always enable the post-copy feature
when starting a migration. Even if they expect to try to get it to
complete using exclusively pre-copy in the common case, its useful
to have post-copy capability flag enabled, as a get out of jail
free card. ie if migration ends up getting stuck in non-convergance,
or they have a sudden need to urgently complete the migration it is
good to be able to flip to post-copy mode.

I'd suggest that we instead add a multifd+postcopy test case to
migration-test.c and tackle any bugs it exposes. By blocking it
unconditionally we ensure no one will exercise it to expose any
further bugs.

> Suggested-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> Signed-off-by: Leonardo Bras <leobras@redhat.com>
> ---
>  migration/migration.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/migration/migration.c b/migration/migration.c
> index ae2025d9d8..c601964b0e 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -1356,6 +1356,11 @@ static bool migrate_caps_check(bool *cap_list,
>              error_setg(errp, "Postcopy is not compatible with ignore-shared");
>              return false;
>          }
> +
> +        if (cap_list[MIGRATION_CAPABILITY_MULTIFD]) {
> +            error_setg(errp, "Postcopy is not yet compatible with multifd");
> +            return false;
> +        }
>      }
>  
>      if (cap_list[MIGRATION_CAPABILITY_BACKGROUND_SNAPSHOT]) {
> -- 
> 2.40.0
> 
> 

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 :|



  parent reply	other threads:[~2023-03-30 14:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-27 16:15 [RFC PATCH v1 1/1] migration: Disable postcopy + multifd migration Leonardo Bras
2023-03-27 16:28 ` Peter Xu
2023-03-28 10:59 ` Dr. David Alan Gilbert
2023-03-30 14:20 ` Daniel P. Berrangé [this message]
2023-03-30 14:36   ` Peter Xu
2023-03-30 14:57     ` Daniel P. Berrangé
2023-03-30 15:59       ` Dr. David Alan Gilbert
2023-03-30 22:18         ` Peter Xu
2023-03-31  5:51           ` Leonardo Brás

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=ZCWanp5hITk4HImX@redhat.com \
    --to=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=leobras@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 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.