Re: [Qemu-devel] [PATCH 2.1 00/28] Current state of NUMA series, and hostmem improvements

[Igor Mammedov]

On Fri, 07 Mar 2014 14:35:09 +0100
Paolo Bonzini <address@hidden> wrote:

> Il 07/03/2014 13:56, Igor Mammedov ha scritto:
> >> However, I'd still like it to be mostly a container, and that is why I
> >> liked the idea of having /node[n] with "flat" links to the actual
> >> CPUStates (and also memdevs).
> >
> > Is there a point in having flat links to CPUState at /nodeX level,
> 
> Easily getting thread ids for the VCPU thread and pinning them to host 
> nodes?  For this you need to match the CPU numbers passed to "-numa 
> node", not some socket topology that can be completely arbitrary.
CPU numbers, on -numa node, are coming from cpu_index legacy, and shouldn't
we try to get rid of it in favor of something manageable?
Since CPUs are now devices we could use "id" to specify CPUs on -numa node
as one solution or use path names as with memdev.


> 
> Paolo
> 
> > idea to create [*] /node[x]/socket[y]/core[z]/link<CPUstate>[j] tree, was
> > suggested as way:
> >  1. to expose stable arch independent topology interface to user
> >  2. use * as argument to -device / device_add/del cpu,path=foo to avoid
> >     exposing arch dependent APIC ID to the user.
> > while keeping /machine/node/socket/core objects mostly as containers to 
> > express
> > above things.
> >
> >>
> >>>> I think we can.  Children and links look exactly the same from the 
> >>>> outside.
> >>>
> >>> Well, we can't qom-get/qom-set a path string from/to a child<> property,
> >>> can we?
> >>
> >> We can get it but not set it.  But Stefan's series provides a way to
> >> make links read-only too, and these links should be read-only I think.
> > CPUState links are readonly only until no hotplug supported.
> >
> >>
> >> Paolo
> >
> >
> 


-- 
Regards,
  Igor