[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 02/21] migration: Don't use INT64_MAX for unlimited rate
From: |
Juan Quintela |
Subject: |
Re: [PATCH 02/21] migration: Don't use INT64_MAX for unlimited rate |
Date: |
Mon, 15 May 2023 13:18:08 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Cédric Le Goater <clg@kaod.org> wrote:
> On 5/9/23 13:51, Juan Quintela wrote:
>> Harsh Prateek Bora <harshpb@linux.ibm.com> wrote:
>>> On 5/8/23 18:38, Juan Quintela wrote:
>>>> Use 0 instead.
>>>> Signed-off-by: Juan Quintela <quintela@redhat.com>
>>>> ---
>>>> migration/migration.c | 4 ++--
>>>> migration/qemu-file.c | 3 +++
>>>> 2 files changed, 5 insertions(+), 2 deletions(-)
>>>> diff --git a/migration/migration.c b/migration/migration.c
>>>> index 1192f1ebf1..3979a98949 100644
>>>> --- a/migration/migration.c
>>>> +++ b/migration/migration.c
>>>> @@ -2296,7 +2296,7 @@ static void migration_completion(MigrationState *s)
>>>> }
>>>> if (ret >= 0) {
>>>> s->block_inactive = !migrate_colo();
>>>> - qemu_file_set_rate_limit(s->to_dst_file, INT64_MAX);
>>>> + qemu_file_set_rate_limit(s->to_dst_file, 0);
>>>
>>> #define RATE_LIMIT_MAX 0
>>>
>>> How about having a macro and use that which conveys the meaning in all
>>> call instances wherever it is getting passed ?
>> I almost preffer the macro.
>> qemu_file_set_rate_limit(s->to_dst_file, RATE_LIMIT_MAX);
>> seems quite explanatory?
>
> yep. and I would drop the comment qemu_file_rate_limit().
I dropped it once by error.
And reviewer didn't noticed either.
So ....
[PATCH 03/21] migration: We set the rate_limit by a second, Juan Quintela, 2023/05/08
[PATCH 04/21] qemu-file: make qemu_file_[sg]et_rate_limit() use an uint64_t, Juan Quintela, 2023/05/08
[PATCH 05/21] qemu-file: Make rate_limit_used an uint64_t, Juan Quintela, 2023/05/08
[PATCH 06/21] qemu-file: Remove total from qemu_file_total_transferred_*(), Juan Quintela, 2023/05/08
[PATCH 08/21] migration: Move setup_time to mig_stats, Juan Quintela, 2023/05/08