From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: qemu-devel@nongnu.org,
Leonardo Bras Soares Passos <lsoaresp@redhat.com>,
Eric Blake <eblake@redhat.com>,
Juan Quintela <quintela@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Chensheng Dong <chdong@redhat.com>, Zhiyi Guo <zhguo@redhat.com>,
Fabiano Rosas <farosas@suse.de>
Subject: Re: [PATCH] migration: Allow user to specify migration available bandwidth
Date: Tue, 25 Jul 2023 17:09:57 +0100 [thread overview]
Message-ID: <ZL/z1e/VATzZN10E@redhat.com> (raw)
In-Reply-To: <ZL/wTBP/7ZdM9Xd4@x1n>
On Tue, Jul 25, 2023 at 11:54:52AM -0400, Peter Xu wrote:
> We can make the semantics specific, no strong opinion here. I wished it
> can be as generic / easy as possible but maybe I went too far.
>
> Though, is there anything else we can choose from besides
> "max-convergence-bandwidth"? Or am I the only one that thinks it's hard to
> understand when put "max" and "convergence" together?
>
> When I take one step back to look at the whole "bandwidth" parameters, I am
> not sure why we'd even need both "convergence" and "postcopy" bandwidth
> being separate. With my current understanding of migration, we may
> actually need:
>
> - One bandwidth that we may want to run the background migration, aka,
> precopy migration, where we don't rush on pushing data.
>
> - One bandwidth that is whatever we can have maximum; for dedicated NIC
> that's the line speed. We should always use this full speed for
> important things. I'd say postcopy falls into this, and this
> "convergence" calculation should also rely on this.
I don't think postcopy should be assumed to run at line speed.
At the point where you flip to post-copy mode, there could
conceivably still be GB's worth of data still dirty and
pending transfer.
The migration convergance step is reasonable to put at line
speed, because the max downtime parameter caps how long this
burst will be, genrally to some fraction of a second.
Once in post-copy mode, while the remaining data to transfer
is finite, the wall clock time to complete that transfer may
still be huge. It is unreasonable to assume users want to
run at max linespeed for many minutes to finish post-copy
at least in terms of the background transfer. You could make
a case for the page fault handling to run at a higher bandwidth
cap than the background transfer, but I think it is still probably
not reasonable to run page fault fetches at line speed by default.
IOW, I don't think we can put the same bandwidth limit on the
short convergance operation, as on the longer post-copy operation.
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:[~2023-07-25 16:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-24 17:07 [PATCH] migration: Allow user to specify migration available bandwidth Peter Xu
2023-07-24 18:04 ` Daniel P. Berrangé
2023-07-24 18:12 ` Peter Maydell
2023-07-24 19:47 ` Peter Xu
2023-07-25 9:16 ` Daniel P. Berrangé
2023-07-25 15:54 ` Peter Xu
2023-07-25 16:09 ` Daniel P. Berrangé [this message]
2023-07-25 16:38 ` Peter Xu
2023-07-25 17:10 ` Daniel P. Berrangé
2023-07-26 15:19 ` Peter Xu
2023-07-25 11:10 ` Markus Armbruster
2023-07-25 16:42 ` Peter Xu
2023-07-26 6:21 ` Markus Armbruster
2023-07-26 15:12 ` Peter Xu
2023-08-04 12:06 ` Markus Armbruster
2023-08-04 13:28 ` Peter Xu
2023-08-05 8:13 ` Markus Armbruster
2023-08-04 13:39 ` Daniel P. Berrangé
2023-08-04 14:02 ` Peter Xu
2023-08-05 8:05 ` Markus Armbruster
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=ZL/z1e/VATzZN10E@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=chdong@redhat.com \
--cc=eblake@redhat.com \
--cc=farosas@suse.de \
--cc=lsoaresp@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=zhguo@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).