On Fri, Sep 07, 2007 at 09:55:45AM -0400, beth kon wrote:
Daniel Veillard wrote:
which would return an XML instance as in virConnectGetCapabilities. I toyed with the idea of extending virConnectGetCapabilities() to add a topology section in case of NUMA support at the hypervisor level, but it was looking to me that the two might be used at different times and separating both might be a bit cleaner, but I could be convinced otherwise. This doesn't change much the content in any way. I think the most important in the call is to get the topology informations as the number of processors, memory and NUMA cells are already available from virNodeGetInfo(). I suggest a format exposing the hierarchy in the XML structure, which will allow for more complex topologies for example on Sun hardware:
--------------------------------- <topology>
One small suggestion here... I've seen the term numanode used in some recent Xen patches. It would seem clearer to replace "cell(s)" with "numanode(s)". Then it is immediately evident what is being referred to, yet doesn't interfere with the libvirt term "node".
<cells num='2'>
Hum, I don't have any strong opinion one way or another, cell sounds a bit more different so I guess there is less confusion. Using google it seems that 'numa cell' show up more frequently than 'numa node'. On the other hand the NUMA FAQ gives a definition of the later http://lse.sourceforge.net/numa/faq/index.html#what_is_a_node Cell was short and looking unambiguous in our context, since we already use Node to name the physical machine, that's why I suggested this. More opinions on the matter ? ;-) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/