[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/2] migration/multifd: Further remove the SYNC on complete
From: |
Peter Xu |
Subject: |
Re: [PATCH 1/2] migration/multifd: Further remove the SYNC on complete |
Date: |
Thu, 5 Dec 2024 17:00:26 -0500 |
On Thu, Dec 05, 2024 at 06:16:05PM -0300, Fabiano Rosas wrote:
> > We don't need to flush the last pages here, because we flushed it already,
> > in the last find_dirty_block() call where src QEMU finished scanning the
> > last round. Then we set complete_round=true, scan one more round, and the
> > iteration won't complete until the new round sees zero dirty page.
>
> Ok, let's put this in the commit message. As it stands it looks like
> this patch is fixing a bug with 637280aeb2 when instead it's doing
> further optimization, but so it happens that we still require the
> backward compatibility part.
Yes, and as commit message said I didn't attach Fixes and plan not to
backport to stable because there's no real bug that we can hit, as those
SYNCs will always only present at the end of migration, so they cannot harm
anything yet if RAM is the only multifd user.
I can add some of above into commit message. Since I already started
looking at the patch you posted on putting all sync conditions together, I
decided to repost this series with that, and with the rename you suggested
on local/remote. Though I can't name them LOCAL and REMOTE because the
REMOTE will contain LOCAL too. So in reality I renamed them to LOCAL and
ALL, comment will explain that ALL contains LOCAL and REMOTE flushes.
--
Peter Xu
[PATCH 2/2] migration/multifd: Allow to sync with sender threads only, Peter Xu, 2024/12/05