Elena Ufimtseva <elena.ufimts...@oracle.com> writes: > In migration rate limiting atomic operations are used > to read the rate limit variables and transferred bytes and > they are expensive. Check first if rate_limit_max is equal > to RATE_LIMIT_DISABLED and return false immediately if so. > > Signed-off-by: Elena Ufimtseva <elena.ufimts...@oracle.com> > --- > migration/migration-stats.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/migration/migration-stats.c b/migration/migration-stats.c > index 095d6d75bb..abc31483d5 100644 > --- a/migration/migration-stats.c > +++ b/migration/migration-stats.c > @@ -24,14 +24,14 @@ bool migration_rate_exceeded(QEMUFile *f) > return true; > } > > - uint64_t rate_limit_start = stat64_get(&mig_stats.rate_limit_start); > - uint64_t rate_limit_current = migration_transferred_bytes(f);
There's a qemu_fflush() hiding inside migration_transferred_bytes(). It currently always flushes if we haven't detected an error in the file. After this patch we will stop flushing at this point if ratelimiting is disabled. You might want to add that information to the commit message to make it easier to track if this ends up causing a regression. Reviewed-by: Fabiano Rosas <faro...@suse.de>
