qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v1 3/8] migration: Introduce dirty-limit capability


From: Hyman Huang
Subject: Re: [PATCH v1 3/8] migration: Introduce dirty-limit capability
Date: Fri, 2 Sep 2022 22:15:53 +0800
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0



在 2022/9/2 16:07, 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
migratioin-set-capabilities, and set the parameters

migrate-set-capabilities

"x-vcpu-dirty-limit-period", "vcpu-dirty-limit" suitably

"x-vcpu-dirty-limit"

to speed up convergence.

Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>

Hmm.  You make dirty-limiting as a whole a stable interface (evidence:
capability "dirty-limit" is stable), but keep its two parameters
unstable.  Rationale behind that?

Thanks Markus's comments. :)

x-vcpu-dirty-limit-period is an experimental parameter indeed, as to x-vcpu-dirty-limit, i think it's resonable to be a stable parameter. These 2 parameters are introduced first time and none of them suffer heavily tests, so i also made vcpu-dirty-limit experimental last version.

For dirty-limit interface, it improves the vCPU computational performance during migration indeed(see the test results in cover letter), so it sounds ok to be an stable interface.

The 'x-vcpu-dirty-limit-period' parameter can be dropped, IMHO, after being proved insignificant for migration in the future, and meanwhile, x-vcpu-dirty-limit be made stable.

Since I don't have much experience to introducing fresh new interface,
any suggestions are welcome.

--
Best regard

Hyman Huang(黄勇)



reply via email to

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