[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v5 05/17] migration: Create x-multifd-threads pa
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] [PATCH v5 05/17] migration: Create x-multifd-threads parameter |
Date: |
Tue, 8 Aug 2017 10:44:11 +0100 |
User-agent: |
Mutt/1.8.3 (2017-05-23) |
* Juan Quintela (address@hidden) wrote:
> "Dr. David Alan Gilbert" <address@hidden> wrote:
> > * Juan Quintela (address@hidden) wrote:
> >> Indicates the number of threads that we would create. By default we
> >> create 2 threads.
> >>
> >> Signed-off-by: Juan Quintela <address@hidden>
> >> Reviewed-by: Dr. David Alan Gilbert <address@hidden>
> >
> > Also needs updating DEFINE_PROP stuff - and if Markus' qapi patch lands.
>
> Done.
>
> >> #
> >> # @return-path: If enabled, migration will use the return path even
> >> # for precopy. (since 2.10)
> >> +#
> >> # @x-multifd: Use more than one fd for migration (since 2.10)
> >> #
> >> # Since: 1.2
> >> @@ -910,6 +911,7 @@
> >> 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
> >> 'compress', 'events', 'postcopy-ram', 'x-colo', 'release-ram',
> >> 'block', 'return-path', 'x-multifd'] }
> >> +
> >
> > Escapee from previous patch.
>
> Done.
>
> >
> >> ##
> >> # @MigrationCapabilityStatus:
> >> #
> >> @@ -1026,13 +1028,19 @@
> >> # migrated and the destination must already have access to the
> >> # same backing chain as was used on the source. (since 2.10)
> >> #
> >> +# @x-multifd-threads: Number of threads used to migrate data in
> >> +# parallel. This is the same number that the
> >> +# number of sockets used for migration.
> >> +# The default value is 2 (since 2.10)
> >> +#
> >
> > That did make me think for a moment; I guess '2' makes sense once you've
> > set the x-multifd capability on. The other possibility would be to
> > remove the capability and just rely on the threads > 1
>
> I think this is the same that xbzrle cache size. It has a default
> value. But we only used it when we set the capability.
>
> I think that it makes the code more ortogonal with the others, no?
I don't have a strong view either way; it's more orthogonal vs one less
parameter. Your choice.
Dave
> Later, Juan.
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK