[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 7/8] multifd: Add multifd-zstd-level parameter
From: |
Markus Armbruster |
Subject: |
Re: [PATCH v5 7/8] multifd: Add multifd-zstd-level parameter |
Date: |
Thu, 13 Feb 2020 15:04:43 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
"Dr. David Alan Gilbert" <address@hidden> writes:
> * Juan Quintela (address@hidden) wrote:
>> Signed-off-by: Juan Quintela <address@hidden>
>> ---
>> migration/migration.c | 15 +++++++++++++++
>> monitor/hmp-cmds.c | 4 ++++
>> qapi/migration.json | 29 ++++++++++++++++++++++++++---
>> 3 files changed, 45 insertions(+), 3 deletions(-)
>>
>> diff --git a/migration/migration.c b/migration/migration.c
>> index 3b081e8147..b690500545 100644
>> --- a/migration/migration.c
>> +++ b/migration/migration.c
>> @@ -91,6 +91,8 @@
>> #define DEFAULT_MIGRATE_MULTIFD_METHOD MULTIFD_METHOD_NONE
>> /*0: means nocompress, 1: best speed, ... 9: best compress ratio */
>> #define DEFAULT_MIGRATE_MULTIFD_ZLIB_LEVEL 1
>> +/* 0: means nocompress, 1: best speed, ... 20: best compress ratio */
>> +#define DEFAULT_MIGRATE_MULTIFD_ZSTD_LEVEL 1
>>
>> /* Background transfer rate for postcopy, 0 means unlimited, note
>> * that page requests can still exceed this limit.
>> @@ -805,6 +807,8 @@ MigrationParameters *qmp_query_migrate_parameters(Error
>> **errp)
>> params->multifd_method = s->parameters.multifd_method;
>> params->has_multifd_zlib_level = true;
>> params->multifd_zlib_level = s->parameters.multifd_zlib_level;
>> + params->has_multifd_zstd_level = true;
>> + params->multifd_zstd_level = s->parameters.multifd_zstd_level;
>
> Do we really want different 'multifd_...._level's or just one
> 'multifd_compress_level' - or even just reuse the existing
> 'compress-level' parameter.
compress-level, multifd-zlib-level, and multifd-zstd-level apply
"normal" live migration compression, multifd zlib live migration
compression, and multifd zstd live migration compression, respectively.
Any live migration can only use one of the three compressions.
Correct?
> The only tricky thing about combining them is how to handle
> the difference in allowed ranges; When would the right time be
> to check it?
>
> Markus/Eric: Any idea?
To have an informed opinion, I'd have to dig through the migration
code.
Documentation of admissible range will become a bit awkward, too.
Too many migration parameters...