On Fri, Aug 02, 2019 at 01:46:41PM +0800, Ivan Ren wrote: >>>>> s->iteration_start_time = qemu_clock_get_ms(QEMU_CLOCK_REALTIME); >>>>>+ /* >>>>>+ * Update s->iteration_initial_bytes to match >>>s->iteration_start_time. >>>>>+ */ >>>>>+ s->iteration_initial_bytes = migration_total_bytes(s); >>>> >>>>Is this one necessary? We have sent out nothing yet. >>> >>>Yes, currently nothing has been sent yet at this point. >>> >>>Is that better to always match the update of iteration_initial_bytes >>>and iteration_start_time in a explicit way to avoid some potential >missing? >>> >> >>You may get some point. Well after a close look, we may find other >potential >>problem. >>
Well, I guess you need to use another tool to send mail. The format is corrupted. >>1. To be consistency, we need to update iteration_initial_pages too. >> So my opinion is to wrap the update of these three counters into a >helper >> function. So each time all of them. I don't see you reply this one or the mail is corrupted. If we don't update iteration_initial_pages, the initial_pages will mismatch the initial_bytes. Am I right? >>2. In function ram_get_total_transferred_pages, do we missed multifd_bytes? > >In function ram_save_multifd_page, ram pages transferred by multifd threads >is >counted by ram_counters.normal. >You mean other multifd bytes like multifd packet or multifd sync info? > Ok, it is counted in normal. While if my understanding is correct, normal is used to count pages sent by save_normal_page(). Sounds this is misused? >Thanks. > >On Fri, Aug 2, 2019 at 8:49 AM Wei Yang <richardw.y...@linux.intel.com> >wrote: > -- Wei Yang Help you, Help me
