qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v4 06/10] migration: Introduce dirty-limit capability


From: Markus Armbruster
Subject: Re: [PATCH v4 06/10] migration: Introduce dirty-limit capability
Date: Fri, 24 Mar 2023 15:32:28 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Hyman Huang <huangy81@chinatelecom.cn> writes:

> 在 2023/3/24 20:11, Markus Armbruster 写道:
>> huangy81@chinatelecom.cn writes:
>> 
>>> From: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
>>>
>>> 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(黄勇) <huangy81@chinatelecom.cn>
>>> Acked-by: Peter Xu <peterx@redhat.com>
>> [...]
>> 
>>> diff --git a/qapi/migration.json b/qapi/migration.json
>>> index d33cc2d582..b7a92be055 100644
>>> --- a/qapi/migration.json
>>> +++ b/qapi/migration.json
>>> @@ -477,6 +477,8 @@
>>>   #                    will be handled faster.  This is a performance 
>>> feature and
>>>   #                    should not affect the correctness of postcopy 
>>> migration.
>>>   #                    (since 7.1)
>>> +# @dirty-limit: Use dirty-limit to throttle down guest if enabled.
>>> +#               (since 8.0)
>>
>> Feels too terse.  What exactly is used and how?  It's not the capability
>> itself (although the text sure sounds like it).  I guess it's the thing
>> you set with command set-vcpu-dirty-limit.
>>
>> Is that used only when the capability is set?
>
> Yes, live migration set "dirty-limit" value when that capability is set,
> the comment changes to "Apply the algorithm of dirty page rate limit to 
> throttle down guest if capability is set, rather than auto-converge".
>
> Please continue to polish the doc if needed. Thanks.

Let's see whether I understand.

Throttling happens only during migration.

There are two throttling algorithms: "auto-converge" (default) and
"dirty page rate limit".

The latter can be tuned with set-vcpu-dirty-limit.

Correct?

What happens when migration capability dirty-limit is enabled, but the
user hasn't set a limit with set-vcpu-dirty-limit, or canceled it with
cancel-vcpu-dirty-limit?

>>>   #
>>>   # Features:
>>>   # @unstable: Members @x-colo and @x-ignore-shared are experimental.
>>> @@ -492,7 +494,7 @@
>>>              'dirty-bitmaps', 'postcopy-blocktime', 'late-block-activate',
>>>              { 'name': 'x-ignore-shared', 'features': [ 'unstable' ] },
>>>              'validate-uuid', 'background-snapshot',
>>> -           'zero-copy-send', 'postcopy-preempt'] }
>>> +           'zero-copy-send', 'postcopy-preempt', 'dirty-limit'] }
>>>     ##
>>>   # @MigrationCapabilityStatus:
>> [...]
>> 




reply via email to

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