[email protected] writes: > From: Hyman Huang(黄勇) <[email protected]> > > Introduce "x-vcpu-dirty-limit-period" migration experimental > parameter, which is in the range of 1 to 1000ms and used to > make dirtyrate calculation period configurable. > > Currently with the "x-vcpu-dirty-limit-period" varies, the > total time of live migration changes, test results show the > optimal value of "x-vcpu-dirty-limit-period" ranges from > 500ms to 1000 ms. "x-vcpu-dirty-limit-period" should be made > stable once it proves best value can not be determined with > developer's experiments.
I'm not a native speaker, but let me try to polish your prose anyway: The value of "x-vcpu-dirty-limit-period" affects how long live migration takes. In my testing, the optimal value of "x-vcpu-dirty-limit-period" ranges from 500ms to 1000 ms. If we can find a single value that is good enough for all use cases that matter, "x-vcpu-dirty-limit-period" can go away. Else, "x-vcpu-dirty-limit-period" should be made stable. Does this capture your intent? > Signed-off-by: Hyman Huang(黄勇) <[email protected]> [...] > diff --git a/qapi/migration.json b/qapi/migration.json > index 88ecf86..c428bcd 100644 > --- a/qapi/migration.json > +++ b/qapi/migration.json > @@ -776,8 +776,13 @@ > # block device name if there is one, and to their > node name > # otherwise. (Since 5.2) > # > +# @x-vcpu-dirty-limit-period: Periodic time (in milliseconds) of dirty limit > during > +# live migration. Should be in the range 1 to > 1000ms, > +# defaults to 1000ms. (Since 7.3) 8.0, not 7.3, unless we change our versioning habits. More of the same below and later in this series; I'm not flagging it again. > +# > # Features: > -# @unstable: Member @x-checkpoint-delay is experimental. > +# @unstable: Members @x-checkpoint-delay and @x-vcpu-dirty-limit-period > +# are experimental. > # > # Since: 2.4 > ## [...]
