[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 01/10] migration: Increase default number of multifd chann
Daniel P . Berrangé
Re: [PATCH v2 01/10] migration: Increase default number of multifd channels to 16
Fri, 3 Jan 2020 17:12:33 +0000
On Fri, Jan 03, 2020 at 05:01:14PM +0000, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (address@hidden) wrote:
> > On Wed, Dec 18, 2019 at 03:01:10AM +0100, Juan Quintela wrote:
> > > We can scale much better with 16, so we can scale to higher numbers.
> > What was the test scenario showing such scaling ?
> > In the real world I'm sceptical that virt hosts will have
> > 16 otherwise idle CPU cores available that are permissible
> > to use for migration, or indeed whether they'll have network
> > bandwidth available to allow 16 cores to saturate the link.
> With TLS or compression, the network bandwidth could easily be there.
Yes, but this constant is setting a default that applies regardless of
whether TLS / compression is enabled and/or whether CPU cores are idle.
IOW, there can be cases where using 16 threads will be a perf win, I'm
just questioning the suitability as a global default out of the box.
I feel like what's really lacking with migration is documentation
around the usefulness of the very many parameters, and the various
interesting combinations & tradeoffs around enabling them. So instead
of changing the default threads, can we focusing on improving
documentation so that mgmt apps have good information on which to
make the decision about whether & when to use 2 or 16 or $NNN migration
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Re: [PATCH v2 01/10] migration: Increase default number of multifd channels to 16, Daniel P . Berrangé, 2020/01/03