[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] migration: always initial ram_counters for a ne
From: |
Wei Yang |
Subject: |
Re: [Qemu-devel] [PATCH] migration: always initial ram_counters for a new migration |
Date: |
Fri, 2 Aug 2019 13:59:04 +0800 |
User-agent: |
Mutt/1.9.4 (2018-02-28) |
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 <address@hidden>
>wrote:
>
--
Wei Yang
Help you, Help me