On Tue, Feb 6, 2024 at 8:25 PM Peter Xu <pet...@redhat.com> wrote: > > On Tue, Feb 06, 2024 at 11:19:05PM +0000, Hao Xiang wrote: > > diff --git a/migration/multifd.c b/migration/multifd.c > > index 25cbc6dc6b..a20d0ed10e 100644 > > --- a/migration/multifd.c > > +++ b/migration/multifd.c > > @@ -264,6 +264,7 @@ static void multifd_send_fill_packet(MultiFDSendParams > > *p) > > packet->flags = cpu_to_be32(p->flags); > > packet->pages_alloc = cpu_to_be32(p->pages->allocated); > > packet->normal_pages = cpu_to_be32(p->normal_num); > > + packet->zero_pages = cpu_to_be32(p->zero_num); > > This doesn't look right.. > > If to fill up the zero accounting only, we shouldn't be touching multifd > packet at all since multifd zero page detection is not yet supported. > > We should only reference mig_stats.zero_pages.
p->zero_num will always be 0 because multifd zero page checking is not yet enabled. The next commit will contain the code to calculate p->zero_num for each packet. This is just a preparation for the next commit that enables the feature. Main migration thread zero page goes through a different format. We are using the same counter mig_stats.zero_pages to track zero pages for both the legacy zero page checking and multifd zero page checking. These two are mutually exclusive so zero page will not be double counted. Let me know if I am missing something. > > > packet->next_packet_size = cpu_to_be32(p->next_packet_size); > > packet->packet_num = cpu_to_be64(p->packet_num); > > -- > Peter Xu >
