On Thu, Jul 13, 2023 at 8:44 PM Markus Armbruster <arm...@redhat.com> wrote:
> ~hyman <hy...@git.sr.ht> writes:
>
> > From: Hyman Huang(黄勇) <yong.hu...@smartx.com>
> >
> > Introduce migration dirty-limit capability, which can
> > be turned on before live migration and limit dirty
> > page rate durty live migration.
> >
> > Introduce migrate_dirty_limit function to help check
> > if dirty-limit capability enabled during live migration.
> >
> > Meanwhile, refactor vcpu_dirty_rate_stat_collect
> > so that period can be configured instead of hardcoded.
> >
> > dirty-limit capability is kind of like auto-converge
> > but using dirty limit instead of traditional cpu-throttle
> > to throttle guest down. To enable this feature, turn on
> > the dirty-limit capability before live migration using
> > migrate-set-capabilities, and set the parameters
> > "x-vcpu-dirty-limit-period", "vcpu-dirty-limit" suitably
> > to speed up convergence.
> >
> > Signed-off-by: Hyman Huang(黄勇) <yong.hu...@smartx.com>
> > Acked-by: Peter Xu <pet...@redhat.com>
> > Reviewed-by: Juan Quintela <quint...@redhat.com>
>
> [...]
>
> > diff --git a/qapi/migration.json b/qapi/migration.json
> > index e43371955a..031832cde5 100644
> > --- a/qapi/migration.json
> > +++ b/qapi/migration.json
> > @@ -497,6 +497,15 @@
> > # are present. 'return-path' capability must be enabled to use
> > # it. (since 8.1)
> > #
> > +# @dirty-limit: If enabled, migration will use the dirty-limit
> > +# algorithm to throttle down guest instead of auto-converge
> > +# algorithm. This algorithm only works when vCPU's dirtyrate
>
> Two spaces after sentence-ending punctuation, please.
>
> "dirty rate" with a space, because that's how we spell it elsewhere.
>
> > +# greater than 'vcpu-dirty-limit', read processes in guest os
> > +# aren't penalized any more, so the algorithm can improve
> > +# performance of vCPU during live migration. This is an optional
> > +# performance feature and should not affect the correctness of the
> > +# existing auto-converge algorithm. (since 8.1)
> > +#
>
> I'm still confused.
>
> The text suggests there are two separate algorithms "to throttle down
> guest": "auto converge" and "dirty limit", and we get to pick one.
> Correct?
>
Yes, indeed !
>
> If it is correct, then the last sentence feels redundant: picking
> another algorithm can't affect the algorithm we're *not* using. What
> are you trying to express here?
>
What i want to express is that the new algorithm implementation does
not affect the original algorithm, leaving it in the comments seems
redundant indeed. I'll drop this in the next version.
>
> When do we use "auto converge", and when do we use "dirty limit"?
>
> What does the user really need to know about these algorithms? Enough
> to pick one, I guess. That means advantages and disadvantages of the
> two algorithms. Which are?
1. The implementation of dirty-limit is based on dirty-ring, which is
qualified
to big systems with huge memories and can improve huge guest VM
responsiveness remarkably during live migration. As a consequence,
dirty-limit
is recommended on platforms with huge guest VMs as is the way with
dirty-ring.
2. dirty-limit convergence algorithm does not affect the "read-process" in
guest
VM, so guest VM gains the equal read performance nearly as it runs on
host
during the live migration. As a result, dirty-limit is recommended if
the guest
VM requires a stable read performance.
The above explanation is about the recommendation of dirty-limit, please
review,
if it's ok, i'll place it in the comment of the dirty-limit capability.
>
> > # Features:
> > #
> > # @unstable: Members @x-colo and @x-ignore-shared are experimental.
> > @@ -512,7 +521,8 @@
> > 'dirty-bitmaps', 'postcopy-blocktime', 'late-block-activate',
> > { 'name': 'x-ignore-shared', 'features': [ 'unstable' ] },
> > 'validate-uuid', 'background-snapshot',
> > - 'zero-copy-send', 'postcopy-preempt', 'switchover-ack'] }
> > + 'zero-copy-send', 'postcopy-preempt', 'switchover-ack',
> > + 'dirty-limit'] }
> >
> > ##
> > # @MigrationCapabilityStatus:
>
> [...]
>
> Thank Markus again for the attention to this patchset. :)
Yong
--
Best regards
