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@xxxxxxxxxx
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list