[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 23/23] migration: Use multifd before we check for the zero
From: |
Juan Quintela |
Subject: |
Re: [PATCH v3 23/23] migration: Use multifd before we check for the zero page |
Date: |
Thu, 02 Dec 2021 18:38:27 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> * Juan Quintela (quintela@redhat.com) wrote:
>> So we use multifd to transmit zero pages.
>>
>> Signed-off-by: Juan Quintela <quintela@redhat.com>
>> ---
>> migration/ram.c | 22 +++++++++++-----------
>> 1 file changed, 11 insertions(+), 11 deletions(-)
>>
>> diff --git a/migration/ram.c b/migration/ram.c
>> index 57efa67f20..3ae094f653 100644
>> --- a/migration/ram.c
>> +++ b/migration/ram.c
>> @@ -2138,6 +2138,17 @@ static int ram_save_target_page(RAMState *rs,
>> PageSearchStatus *pss,
>> ram_addr_t offset = ((ram_addr_t)pss->page) << TARGET_PAGE_BITS;
>> int res;
>>
>> + /*
>> + * Do not use multifd for:
>> + * 1. Compression as the first page in the new block should be posted
>> out
>> + * before sending the compressed page
>> + * 2. In postcopy as one whole host page should be placed
>> + */
>> + if (!save_page_use_compression(rs) && migrate_use_multifd()
>> + && !migration_in_postcopy()) {
>> + return ram_save_multifd_page(rs, block, offset);
>> + }
>> +
>> if (control_save_page(rs, block, offset, &res)) {
>> return res;
>> }
>
> Although I don't think it currently matters, I think that should be
> after the control_save_page.
This needs to be improved to be compatible with old versions.
But .... if we don't care about RDMA, why do we care about
control_save_page()?
Later, Juan.