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

[Andrew Jones]

On Fri, Nov 07, 2014 at 10:52:31AM +0100, Andrew Jones wrote:
> 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.

After talking with Igor, it seems like the better approach is to get
smp parameters converted over to machine properties, allowing us to
use the old parser for old machine types, and the new for new. I'll
look into it.

drew