qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC 0/6] enable numa configuration before machine_init


From: Igor Mammedov
Subject: Re: [Qemu-devel] [RFC 0/6] enable numa configuration before machine_init() from HMP/QMP
Date: Wed, 18 Oct 2017 16:21:25 +0200

On Wed, 18 Oct 2017 13:27:15 +0100
"Daniel P. Berrange" <address@hidden> wrote:

> On Wed, Oct 18, 2017 at 02:19:54PM +0200, Paolo Bonzini wrote:
> > On 17/10/2017 17:07, Daniel P. Berrange wrote:  
> > > ie instead of:
> > > 
> > >   -smp 8,sockets=4,cores=2,threads=1
> > >   -numa node,nodeid=0,cpus=0-3
> > >   -numa node,nodeid=1,cpus=4-7
> > > 
> > > we could do:
> > > 
> > >   -object numa-node,id=numa0
> > >   -object numa-node,id=numa1
> > >   -object cpu,id=cpu0,node=numa0,socket=0,core=0,thread=0
> > >   -object cpu,id=cpu1,node=numa0,socket=0,core=1,thread=0
> > >   -object cpu,id=cpu2,node=numa0,socket=1,core=0,thread=0
> > >   -object cpu,id=cpu3,node=numa0,socket=1,core=1,thread=0
> > >   -object cpu,id=cpu4,node=numa1,socket=2,core=0,thread=0
> > >   -object cpu,id=cpu5,node=numa1,socket=2,core=1,thread=0
> > >   -object cpu,id=cpu6,node=numa1,socket=3,core=0,thread=0
> > >   -object cpu,id=cpu7,node=numa1,socket=3,core=1,thread=0
> > > 
> > > (perhaps -device instead of -object above, but that's a minor detail)  
> > 
> > I understand that this is just an example, but wasn't this what is solved by
> > 
> >   -smp 8,sockets=4,cores=2,thread=1
> >   -numa node,nodeid=0 -numa cpu,node-id=0,socket-id=0-1
> >   -numa node,nodeid=1 -numa cpu,node-id=0,socket-id=2-3  
> 
> IIUC, that lets you associate CPUs with NUMA nodes without having to know
> the internal QEMU indexes. 
yep with -numa cpu, user don't need to know cpu_index-es anymore,
but the next thing to know for user is:
  1: set of properties machine supports
      x86: "{socket|core|thread}-id"
      spapr: "core-id"
      s390: ...
  2: what values to use for above properties,
     they might be 0..n interval but also might be sparse
     (spapr for example), in other words values owned by machine
     and might also depend on its version.

above 2 points were a reason why query-hotpluggable-cpus
had been introduced so that mgmt would query qemu for valid set
of properties/values for a given set of options so it could
compose a valid device_add command for hotplug.

I'm not opposed to adding
  -smp 0 -device foo-cpu,id=cpuX,...
as Daniel suggests but libvirt would have to implement logic that
makes up #1+#2 (which probably means duplicating it from qemu)


>It won't help you with any monitor commands you
> need to run later that expect the CPU index as input value.  My example
> where lets you assign IDs to each CPU, which can then be used for montor
> commands too - i should have illustrated that bit of it too.
monitor commands that take cpu-index is a separate not related story though.
They needs to be worked on to use socket|core|thread-id where it makes
sense.
(
For ex: spapr core can't be used as address with 'cpu' command as it
expects to thread level object stored and other commands would operate on/
expect CPUState being pointed out. Introducing explicit ID set by mgmt
won't be of use here either is it will set for core object while children
threads will be name-less.
In such usecases we can use qom path to thread of interest which
could be queried in runtime with query-cpus that gives thread level view.
)
 
> Regards,
> Daniel




reply via email to

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