Hi, Eric On 2020/2/21 22:14, Eric Blake wrote: > On 2/20/20 8:57 PM, Keqian Zhu wrote: >> Currently, if the bytes_dirty_period is more than the 50% of >> bytes_xfer_period, we start or increase throttling. >> >> If we make this percentage higher, then we can tolerate higher >> dirty rate during migration, which means less impact on guest. >> The side effect of higher percentage is longer migration time. >> >> We can configure this parameter to switch between migration time >> firt or guest performance first. The default value is 50. >> >> Signed-off-by: Keqian Zhu <zhukeqi...@huawei.com> >> --- >> Cc: Juan Quintela <quint...@redhat.com> >> Cc: "Dr. David Alan Gilbert" <dgilb...@redhat.com> >> Cc: Eric Blake <ebl...@redhat.com> >> Cc: Markus Armbruster <arm...@redhat.com> >> --- > >> +++ b/qapi/migration.json >> @@ -524,6 +524,10 @@ >> # compression, so set the decompress-threads to the >> number about 1/4 >> # of compress-threads is adequate. >> # >> +# @throttle-trig-thres: The ratio of bytes_dirty_period and >> bytes_xfer_period to >> +# trigger throttling. It is expressed as percentage. >> The >> +# default value is 50. (Since 5.0) >> +# > > Abbreviating feels odd; can you please spell this out as > throttle-trigger-threshold? OK, I will use full name in v2. > > Can the threshold exceed 100%? If the threshold exceed 100% and the dirty rate is between 100% and threshold, then throttling will not be started, so the migration will not converge and last an uncertain time until the workload in guest is down by itself. So I think that the threshold exceed 100% maybe not suitable :). >
Thanks. Keqian
