Re: [Qemu-devel] [PATCH] migration: always initial ram_counters for a new migration

[Wei Yang <richardw.yang@linux.intel.com>]

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.yang@linux.intel.com>
>wrote:
>

-- 
Wei Yang
Help you, Help me