On 01/19/2013 12:06 AM, Peter Krempa wrote: > This patch adds RNG schemas for adding more information in the topology > output of the NUMA section in the capabilities XML. > > The added elements are designed to provide more information about the > placement and topology of the processors in the system to management > applications. > > A demonstration of supported XML added by this patch: > <capabilities> > <host> > <topology> > <cells num='3'> > <cell id='0'> > <cpus num='4'> <!-- this is node with Hyperthreading --> > <cpu id='0' socket_id='0' core_id='0' siblings='0-1'/> > <cpu id='1' socket_id='0' core_id='0' siblings='0-1'/> > <cpu id='2' socket_id='0' core_id='1' siblings='2-3'/> > <cpu id='3' socket_id='0' core_id='1' siblings='2-3'/> > </cpus> > </cell> > <cell id='1'> > <cpus num='4'> <!-- this is node with modules (Bulldozer) --> > <cpu id='4' socket_id='0' core_id='2' siblings='4-5'/> > <cpu id='5' socket_id='0' core_id='3' siblings='4-5'/> > <cpu id='6' socket_id='0' core_id='4' siblings='6-7'/> > <cpu id='7' socket_id='0' core_id='5' siblings='6-7'/> > </cpus> > </cell> > <cell id='2'> > <cpus num='4'> <!-- this is a normal multi-core node --> > <cpu id='8' socket_id='1' core_id='0' siblings='8'/> > <cpu id='9' socket_id='1' core_id='1' siblings='9'/> > <cpu id='10' socket_id='1' core_id='2' siblings='10'/> > <cpu id='11' socket_id='1' core_id='3' siblings='11'/> > </cpus> > </cell> > </cells> > </topology> > </host> > </capabilities> > > The socket_id field represents identification of the physical socket the > CPU is plugged in. This ID may not be identical to the physical socket > ID reported by the kernel. > > The core_id identifies a core within a socket. Also this field may not > accurately represent physical ID's. > > The core_id is guaranteed to be unique within a cell and a socket. There > may be duplicates between sockets. Only cores sharing core_id within one > cell and one socket can be considered as threads. Cores sharing core_id > within sparate cells are distinct cores. > s/sparate/separate/ > The siblings field is a list of CPU id's the cpu id's the CPU is sibling > with - thus a thread. The list is in the cpuset format. s/CPU id's the cpu id's/CPU IDs/ > --- > docs/schemas/capability.rng | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/docs/schemas/capability.rng b/docs/schemas/capability.rng > index 8c928bc..734ed81 100644 > --- a/docs/schemas/capability.rng > +++ b/docs/schemas/capability.rng > @@ -193,6 +193,17 @@ > <attribute name='id'> > <ref name='unsignedInt'/> > </attribute> > + <optional> > + <attribute name='socket_id'> > + <ref name='unsignedInt'/> > + </attribute> > + <attribute name='core_id'> > + <ref name='unsignedInt'/> > + </attribute> > + <attribute name='siblings'> > + <ref name='cpuset'/> > + </attribute> > + </optional> > </element> > </define> > IMHO this looks very good and it is understandable for management applications. I like that with this approach libvirt isn't obfuscating modules as neither threads nor cores, but rather providing all the information available, so management application can decide what it wants (but doesn't have to). However, I wasn't part of your previous discussion about this and I don't want to skip other's decision on this by simply ACKing it without others expressing their opinion, so small ACK from me. I'd say it can go in if nobody is particularly against it until the freeze. Martin -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list