Re: [PATCH 09/14] migration: Move iteration counter out of RAM

[Peter Xu <peterx@redhat.com>]

On Thu, Apr 09, 2026 at 07:14:15PM -0300, Fabiano Rosas wrote:
> > diff --git a/migration/ram.c b/migration/ram.c
> > index e5b7217bf5..686162643d 100644
> > --- a/migration/ram.c
> > +++ b/migration/ram.c
> > @@ -1136,8 +1136,6 @@ static void migration_bitmap_sync(RAMState *rs, bool last_stage)
> >      RAMBlock *block;
> >      int64_t end_time;
> >  
> > -    qatomic_add(&mig_stats.dirty_sync_count, 1);
> > -
> >      if (!rs->time_last_bitmap_sync) {
> >          rs->time_last_bitmap_sync = qemu_clock_get_ms(QEMU_CLOCK_REALTIME);
> 
> Tangent: aren't these updates to time_last_bitmap_sync racy with the
> sync from the throttle code?

It looks fine to me.  This variable (along with log sync) should require
BQL, so I expect normal form of race condition won't happen.

But maybe you meant when migration_bitmap_sync() can be invoked by the
timer kick-offed in cpu_throttle_dirty_sync_timer_tick()?

Indeed that could happen together with the migration thread trying to sync
by other reasons, but so far I see no issues: time_last_bitmap_sync might
get updated sooner, but it should always reflect the time that whoever
synced the last, and when both want to do it they contend on BQL, which
looks ok.

So the expectation is that timer just makes sure sync happens slightly more
frequently, where QEMU src might used to sync toooo less times on huge VMs
(because each iteration took tooo long).

-- 
Peter Xu