qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC 06/16] vl: move smp parsing to machine pre_i


From: Andrew Jones
Subject: Re: [Qemu-devel] [PATCH RFC 06/16] vl: move smp parsing to machine pre_init
Date: Wed, 15 Jun 2016 09:19:05 +0200
User-agent: Mutt/1.5.23.1 (2014-03-12)

On Wed, Jun 15, 2016 at 10:51:08AM +1000, David Gibson wrote:
> On Tue, Jun 14, 2016 at 04:03:29PM +0200, Andrew Jones wrote:
> > On Tue, Jun 14, 2016 at 01:53:05PM +0200, Paolo Bonzini wrote:
> > > 
> > > 
> > > On 14/06/2016 13:39, Andrew Jones wrote:
> > > > On Tue, Jun 14, 2016 at 10:17:49AM +0200, Paolo Bonzini wrote:
> > > >> On 13/06/2016 22:35, Andrew Jones wrote:
> > > >>> On Mon, Jun 13, 2016 at 07:04:01PM +0200, Paolo Bonzini wrote:
> > > >>>> On 10/06/2016 19:40, Andrew Jones wrote:
> > > >> They should just not specify it and get a default of 1. ;)
> > > > 
> > > > Yeah, threads, the only one we should never calculate, could be
> > > > optional. If not specified, defaulting to 1 makes perfect sense.
> > > > But, threads=0, which is weird, but in a way specifying that it's
> > > > not specified, also makes some sense.
> > > 
> > > If it's weird, let's make it invalid. :)
> > 
> > I'm weird, and starting to like it :-)
> > 
> > > 
> > > >>>> - cpus % (cores * threads) != 0
> > > >>>
> > > >>> Hmm. This makes sense where cpus is the number of cpu packages,
> > > >>
> > > >> I'm not sure I understand what you mean here.  The point is that the
> > > >> machine starts with an integral number of sockets.
> > > > 
> > > > OK, s/cpus/maxcpus/ then. By using the currently online number, I
> > > > thought you were starting to prepare for cpu packages, which are
> > > > indivisible sets of cores and threads.
> > > 
> > > Yes, that's what I meant to do.  Isn't cpus what you call
> > > "total-online-threads" below?
> > 
> > It is. I was thinking it may need to be redefined if we wanted to
> > hotplug these "indivisible sets of cores and threads" (sockets),
> > instead of what we do today, which is to hotplug one "cpu" at a time.
> > However, I just chatted with Igor, and he says cpu hotplug operates
> > on logical processors, and thus it's fine to talk about hotplugging
> > threads. Even real hardware does this. Real hardware will plug a
> > socket full of threads, but then the firmware may keep most of them
> > disabled until they're "hotplugged". So, I think the value of cpus
> > can be anything. Even the useless value of zero.
> 
> Uh.. this depends on the platform (machine type).  ACPI allows
> (logical) hotplugging of individual threads.  However on pseries the
> hotplug mechanism works at core granularity only.  I don't know of
> real examples off hand, but it's easy to imagine a platform interface
> which worked at socket, or even a multi-socket-module level
> 
> In other words the "cpu package" doesn't necessarily lie at a fixed
> level of the thread/core/socket heirarchy.
> 
> This is something we're grappling with in trying to implement
> cross-platform cpu hotplug, and we obviously don't want to make it
> worse with these -smp changes.

Right now we're bringing hotplug up in this discussion purely to set
the largest range of inputs for each of the five properties, in
order to do a first pass of sanity checks. If a particular machine
has a stricter range for a given property then it's free to override
pre-init and do what it likes. If pre-init gets used for non-smp
related stuff in the future then we'll make a specific smp-init machine
method, allowing smp init to always be easily overridden by machines.

Thanks,
drew



reply via email to

[Prev in Thread] Current Thread [Next in Thread]