Yong Huang <yong.hu...@smartx.com> writes: > On Thu, Jul 13, 2023 at 8:44 PM Markus Armbruster <arm...@redhat.com> wrote: > >> ~hyman <hy...@git.sr.ht> writes: >> >> > From: Hyman Huang(黄勇) <yong.hu...@smartx.com> >> > >> > 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(黄勇) <yong.hu...@smartx.com> >> > Acked-by: Peter Xu <pet...@redhat.com> >> > Reviewed-by: Juan Quintela <quint...@redhat.com> >> >> [...] >> >> > diff --git a/qapi/migration.json b/qapi/migration.json >> > index e43371955a..031832cde5 100644 >> > --- a/qapi/migration.json >> > +++ b/qapi/migration.json >> > @@ -497,6 +497,15 @@ >> > # are present. 'return-path' capability must be enabled to use >> > # it. (since 8.1) >> > # >> > +# @dirty-limit: If enabled, migration will use the dirty-limit >> > +# algorithm to throttle down guest instead of auto-converge >> > +# algorithm. This algorithm only works when vCPU's dirtyrate >> >> Two spaces after sentence-ending punctuation, please. >> >> "dirty rate" with a space, because that's how we spell it elsewhere. >> >> > +# greater than 'vcpu-dirty-limit', read processes in guest os >> > +# aren't penalized any more, so the algorithm can improve >> > +# performance of vCPU during live migration. This is an optional >> > +# performance feature and should not affect the correctness of the >> > +# existing auto-converge algorithm. (since 8.1) >> > +# >> >> I'm still confused. >> >> The text suggests there are two separate algorithms "to throttle down >> guest": "auto converge" and "dirty limit", and we get to pick one. >> Correct? >> > Yes, indeed ! > >> >> If it is correct, then the last sentence feels redundant: picking >> another algorithm can't affect the algorithm we're *not* using. What >> are you trying to express here? >> > What i want to express is that the new algorithm implementation does > not affect the original algorithm, leaving it in the comments seems > redundant indeed. I'll drop this in the next version.
Works for me. >> When do we use "auto converge", and when do we use "dirty limit"? >> >> What does the user really need to know about these algorithms? Enough >> to pick one, I guess. That means advantages and disadvantages of the >> two algorithms. Which are? > > 1. The implementation of dirty-limit is based on dirty-ring, which is > qualified > to big systems with huge memories and can improve huge guest VM > responsiveness remarkably during live migration. As a consequence, > dirty-limit > is recommended on platforms with huge guest VMs as is the way with > dirty-ring. > 2. dirty-limit convergence algorithm does not affect the "read-process" in > guest > VM, so guest VM gains the equal read performance nearly as it runs on > host > during the live migration. As a result, dirty-limit is recommended if > the guest > VM requires a stable read performance. > The above explanation is about the recommendation of dirty-limit, please > review, > if it's ok, i'll place it in the comment of the dirty-limit capability. Yes, please. But before that, I have still more questions. "This algorithm only works when vCPU's dirtyrate greater than 'vcpu-dirty-limit'" is a condition: "FEATURE only works when CONDITION". What happens when the condition is not met? How can the user ensure the condition is met? [...]
