> > +++ 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
