Re: [Qemu-devel] [PATCH] vl: rework smp_parse

[Andrew Jones <drjones@redhat.com>]

On Fri, Nov 07, 2014 at 10:40:14AM +0100, Paolo Bonzini wrote:
> 
> 
> On 07/11/2014 10:29, Andrew Jones wrote:
> >> > I think this would cause too many failures in the wild.  Perhaps error
> >> > out if it is lower, and warn if sockets * cores * threads > max_cpus
> >> > since we actually allow hot-plug a thread at a time?
> > We'd still have more failures if we choose to error out when it's lower,
> > since we currently silently adjust threads in some of those cases, or
> > just don't care that the topology doesn't support up to maxcpus in other.
> 
> So I guess we need a decent fallback if it doesn't match.  Something
> like (based also on the reply from Eduardo):
> 
> 1) always warn if max_cpus % (cores*threads) != 0 || smp_cpus %
> (cores*threads) != 0
> 
> 2) if sockets*cpus*threads < max_cpus, adjust sockets to
> DIV_ROUND_UP(max_cpus, cores*threads).  If we didn't warn in step 1, do
> it now.  Give a different, less harsh warning if the cmdline
> sockets*cpus*threads did match smp_cpus.  In the latter case, the user
> _almost_ knows what he was doing.
> 
> Not perfect, but it could be something to start from.  Adjusting sockets
> is better than adjusting threads.

OK. I can whip up a v2 that is less harsh (more warnings, less aborts).
I'll also address the other issue I mentioned in the bottom of my reply
to Eduardo, which is to make sure we consider machine_class->max_cpus.

drew
> 
> Paolo
> 
> > I'm not sure how best to go about modifying the command line semantics
> > in a backwards compatible way, other than to just create a new "-smp"
> > option. I'm open to all opinions and suggestions.