[Libvir] Extending libvirt to probe NUMA topology

Daniel Veillard veillard at redhat.com
Tue Sep 11 09:08:25 UTC 2007


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




More information about the libvir-list mailing list