Hyman Huang <huang...@chinatelecom.cn> writes: > 在 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.
Is the new interface fit for purpose without use of any experimental parameter? If the answer is something like "command dirty-limit improves things even without use of experimental parameters, but using them may well improve things more (but we need more testing to know for sure)", then your current use of 'unstable' may make sense.
