在 2022/9/2 16:07, Markus Armbruster 写道:
huang...@chinatelecom.cn writes:
From: Hyman Huang(黄勇) <huang...@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(黄勇) <huang...@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(黄勇)
