Re: [Qemu-devel] [v4 12/13] migration: Add command to set migration parameter

[Li, Liang Z]

> > +++ b/migration/migration.c
> > @@ -66,9 +66,12 @@ MigrationState *migrate_get_current(void)
> >          .bandwidth_limit = MAX_THROTTLE,
> >          .xbzrle_cache_size = DEFAULT_MIGRATE_CACHE_SIZE,
> >          .mbps = -1,
> > -        .compress_thread_count =
> DEFAULT_MIGRATE_COMPRESS_THREAD_COUNT,
> > -        .decompress_thread_count =
> DEFAULT_MIGRATE_DECOMPRESS_THREAD_COUNT,
> > -        .compress_level = DEFAULT_MIGRATE_COMPRESS_LEVEL,
> > +        .parameters[MIGRATION_PARAMETER_COMPRESS_LEVEL] =
> > +                DEFAULT_MIGRATE_COMPRESS_LEVEL,
> 
> Looks okay.
> 
> > +        .parameters[MIGRATION_PARAMETER_COMPRESS_THREADS] =
> > +                DEFAULT_MIGRATE_COMPRESS_THREAD_COUNT,
> > +        .parameters[MIGRATION_PARAMETER_DECOMPRESS_THREADS] =
> > +                DEFAULT_MIGRATE_DECOMPRESS_THREAD_COUNT,
> 
> Hmm - do we really need two parameters here?  Remember, compress
> threads is used only on the source, and decompress threads is used only on
> the destination.  Having a single parameter, 'threads', which is set to
> compression threads on source and decompression threads on destination,
> and which need not be equal between the two machines, should still work,
> right?
>

Yes, it works. The benefit of using one parameter instead of two can reduce the 
QMP 
command count, and the side effect of using the same thread count for 
compression
 and decompression is a little waste if the user just want to use the default 
settings,
you know, decompression is usually  about 4 times faster than compression.  Use 
more
decompression threads than needed will waste some RAM which used to save data 
structure related to the decompression thread, about 4K bytes RAM per thread, 
is it 
acceptable?

Liang