|
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
[Prev in Thread] | Current Thread | [Next in Thread] |