* Peter Xu (pet...@redhat.com) wrote:
> Commit ba1b7c812c ("migration/ram: Optimize ram_save_host_page()") managed to
> optimize host huge page use case by scanning the dirty bitmap when looking for
> the next dirty small page to migrate.
>
> However when updating the pss->page before returning from that function, we
> used MIN() of these two values: (1) next dirty bit, or (2) end of current sent
> huge page, to fix up pss->page.
>
> That sounds unnecessary, because I see nowhere that requires pss->page to be
> not going over current huge page boundary.
>
> What we need here is probably MAX() instead of MIN() so that we'll start
> scanning from the next dirty bit next time. Since pss->page can't be smaller
> than hostpage_boundary (the loop guarantees it), it probably means we don't
> need to fix it up at all.
>
> Cc: Keqian Zhu <zhukeqi...@huawei.com>
> Cc: Kunkun Jiang <jiangkun...@huawei.com>
> Signed-off-by: Peter Xu <pet...@redhat.com>
Hmm, I think that's potentially necessary. note that the start of
ram_save_host_page stores the 'start_page' at entry.
That' start_page' goes to the ram_save_release_protection and so
I think it needs to be pagesize aligned for the mmap/uffd that happens.
Dave
> ---
> migration/ram.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/migration/ram.c b/migration/ram.c
> index 381ad56d26..94b0ad4234 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -2229,8 +2229,6 @@ static int ram_save_host_page(RAMState *rs,
> PageSearchStatus *pss,
> } while ((pss->page < hostpage_boundary) &&
> offset_in_ramblock(pss->block,
> ((ram_addr_t)pss->page) <<
> TARGET_PAGE_BITS));
> - /* The offset we leave with is the min boundary of host page and block */
> - pss->page = MIN(pss->page, hostpage_boundary);
>
> res = ram_save_release_protection(rs, pss, start_page);
> return (res < 0 ? res : pages);
> --
> 2.32.0
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
