Re: [PATCH QEMU v8 4/9] migration: Introduce dirty-limit capability

[Markus Armbruster <armbru@redhat.com>]

~hyman <hyman@git.sr.ht> writes:

> From: Hyman Huang(黄勇) <yong.huang@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.huang@smartx.com>
> Acked-by: Peter Xu <peterx@redhat.com>
> Reviewed-by: Juan Quintela <quintela@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?

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?

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?

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

[...]