qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v8 1/3] multifd: Create property multifd-flush-after-each-sec


From: Juan Quintela
Subject: Re: [PATCH v8 1/3] multifd: Create property multifd-flush-after-each-section
Date: Wed, 26 Apr 2023 18:55:04 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Peter Xu <peterx@redhat.com> wrote:
> On Tue, Apr 25, 2023 at 06:31:12PM +0200, Juan Quintela wrote:
>> We used to flush all channels at the end of each RAM section
>> sent.  That is not needed, so preparing to only flush after a full
>> iteration through all the RAM.
>> 
>> Default value of the property is false.  But we return "true" in
>> migrate_multifd_flush_after_each_section() until we implement the code
>> in following patches.
>> 
>> Signed-off-by: Juan Quintela <quintela@redhat.com>
>> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
>> Signed-off-by: Juan Quintela <quintela@redhat.com>
>
> PS: Normally I'll just keep the last Sign-off-by for each person. :)

And here we are again O:-)

I have a hook to put that in.  And at some point it did the wrong thing
(i.e. this), and I always forgot to look into old series for this error.

Sorry, fixed.


>> 
>> ---
>> 
>> Rename each-iteration to after-each-section
>> Rename multifd-sync-after-each-section to
>>        multifd-flush-after-each-section
>> ---
>>  hw/core/machine.c     |  1 +
>>  migration/migration.c | 13 +++++++++++++
>>  migration/migration.h | 13 +++++++++++++
>>  3 files changed, 27 insertions(+)
>> 
>> diff --git a/hw/core/machine.c b/hw/core/machine.c
>> index 2ce97a5d3b..32bd9277b3 100644
>> --- a/hw/core/machine.c
>> +++ b/hw/core/machine.c
>> @@ -60,6 +60,7 @@ const size_t hw_compat_7_1_len = 
>> G_N_ELEMENTS(hw_compat_7_1);
>>  GlobalProperty hw_compat_7_0[] = {
>>      { "arm-gicv3-common", "force-8-bit-prio", "on" },
>>      { "nvme-ns", "eui64-default", "on"},
>> +    { "migration", "multifd-flush-after-each-section", "on"},
>>  };
>
> Here we need hw_compat_8_0 instead?

Good catch.

Changed.




reply via email to

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