[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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.

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.

> - 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.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]