[libvirt] [RFC PATCH 0/3] Guest NUMA topology support - v0

[Bharata B Rao]

On Thu, Oct 13, 2011 at 12:53:22PM +0100, Daniel P. Berrange wrote:
> On Mon, Oct 03, 2011 at 03:28:44PM +0530, Bharata B Rao wrote:
> > Hi,
> > 
> > I discussed the possibilities of adding NUMA topology XML specification
> > support for guests here some time back. Since my latest proposal
> > (http://permalink.gmane.org/gmane.comp.emulators.libvirt/44626)
> > didn't get any response, I am posting a prototype implementation
> > that supports specifying NUMA topology for QEMU guests.
> > 
> > - The implementation is based on the last proposal I listed above.
> 
> So we're basically only allowing a flat NUMA toplogy
> 
>      <numa>
>         <node  cpus='0,2,4,6' mems='1024>
>         <node  cpus='8,10,12,14' mems='1024>
>         <node  cpus='1,3,5,7' mems='1024'>
>         <node  cpus='9,11,13,15' mems='1024'>
>      </numa>
> 
> which mirrors what QEMU allows currently. Should we need
> to support a hierarchy, we can trivially extend this
> syntax in a backwards compatible fashion
> 
>      <numa>
>         <node>
>           <node  cpus='0,2,4,6' mems='1024>
>           <node  cpus='8,10,12,14' mems='1024>
>         </node>
>        <node>
>           <node  cpus='1,3,5,7' mems='1024'>
>           <node  cpus='9,11,13,15' mems='1024'>
>        </node>
>      </numa>
> 
> so I think this limitation is OK for now.

Fine then.

> 
> In the virsh capabilities XML, we actually use the
> word 'cell' rather than 'node'. I think it might
> be preferrable to be consistent and use 'cell' here
> too.

I feel NUMA node sounds more familiar than NUMA cell.
But if libvirt prefers cell, we can go with cell I suppose.

> 
> > - The implementation is for QEMU only.
> 
> That's fine.
> 
> > - The patchset has gone through extremely light testing and I have
> >   just tested booting a 2 socket 2 core 2 thread QEMU guest.
> > - I haven't really bothered to cover all the corner cases and haven't
> >   run libvirt tests after this patchset. For eg, there is no code
> >   to validate if the CPU combination specified by <topology> and
> >   <numa> match with each other. I plan to cover all these after we
> >   freeze the specification itself.
> 
> ok
> 
> 
> WRT the question about CPU enumeration order in the URL quoted
> above. I don't think it matters whether we enumerate CPUs in the
> same order as real hardware. The key thing is that we just choose
> an order, document what *our* enumeration order is, and then stick
> to it forever.

Ok fine.

Regards,
Bharata.