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(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/