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.
