[Libvir] Extending libvirt to probe NUMA topology

[beth kon]

Daniel Veillard wrote:

>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
>
>  
>
I see that the term "cell" is already sprinkled around the libvirt code, 
so it may be easier to just leave it as is. It probably won't result in 
much confusion.

-- 
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: eak at us.ibm.com