qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC 1/6] qapi/migration: Introduce vcpu-dirtylimit-period parameter


From: Eric Blake
Subject: Re: [RFC 1/6] qapi/migration: Introduce vcpu-dirtylimit-period parameters
Date: Wed, 18 May 2022 10:05:04 -0500
User-agent: NeoMutt/20220429-71-6f7d3e

On Tue, May 17, 2022 at 02:35:01PM +0800, huangy81@chinatelecom.cn wrote:
> From: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
> 
> Introduce "vcpu-dirtylimit-period" migration parameters,
> which is used to makes dirtyrate calculation period

make

> configurable.
> 
> To implement that, refactor vcpu_dirty_rate_stat_collect
> so that period can be configured instead of hardcode.

hardcoded

> 
> Meanwhile, introduce migrate_dirtylimit function to help
> check if dirtylimit enabled during live migration, set
> it false by default.
> 
> Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
> ---

Focusing just on UI...

> +++ b/qapi/migration.json
> @@ -760,6 +760,9 @@
>  #                        block device name if there is one, and to their 
> node name
>  #                        otherwise. (Since 5.2)
>  #
> +# @vcpu-dirtylimit-period: Periodic time (ms) of dirtylimit during live 
> migration.
> +#                          Defaults to 500ms. (Since 7.0)

The next release is 7.1.  You'll need to fix this and all other references.

Do we want 'dirty-limit' instead of 'dirtylimit'?  There was a recent
thread on how to translate QAPI to other languages that are a bit more
insistent on MixedCase, where properly separating English words makes
it easier to translate to the expected case.

>  ##
>  # @migrate-set-parameters:
> @@ -1125,6 +1132,9 @@
>  #                        block device name if there is one, and to their 
> node name
>  #                        otherwise. (Since 5.2)
>  #
> +# @vcpu-dirtylimit-period: Periodic time (ms) of dirtylimit during live 
> migration.
> +#                          Defaults to 500ms. (Since 7.0)
> +#
>  # Features:
>  # @unstable: Member @x-checkpoint-delay is experimental.

Is this feature ready for prime time, or do we want to initially name
it x-vcpu-dirty[-]limit-period to mark it experimental?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org




reply via email to

[Prev in Thread] Current Thread [Next in Thread]