qemu-devel
[Top][All Lists]
Advanced

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

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 2.1 00/28] Current state of NUMA series, and hostmem improvements
Date: Fri, 07 Mar 2014 14:35:09 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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.

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






reply via email to

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