qemu-devel
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]