Open Stack

On Thu, Feb 05, 2015 at 10:28:56AM -0600, Chris Friesen wrote:
> On 02/04/2015 06:48 PM, Steve Gordon wrote:
> >----- Original Message -----
> >>From: "Chris Friesen" <chris.friesen at windriver.com>
> 
> >>Setting that aside, there's another topic. I haven't actually specified
> >>NUMA bindings, only huge pages, so does it really make sense to require a
> >>quemu with numa binding capability?
> >
> >Dan can probably comment further but looking at the logic used I believe even
> >without a NUMA topology being specified it does make use of topology
> >information to try and line up the huge pages being allocated and the cell
> >the guest is going in. The large pages work was done after the NUMA work
> >with, I suspect, an underlying expectation that most users wanting to use
> >these features would be using all in combination.
> >
> >That's not necessarily to say someone couldn't propose updates to the huge
> >pages implementation to provide a fallback path in this case, but it doesn't
> >appear to be there today.
> 
> 
> For what it's worth, I was able to make hugepages work with an older qemu by
> commenting out two lines in
> virt.libvirt.config.LibvirtConfigGuestMemoryBacking.format_dom()
> 
>     def format_dom(self):
>         root = super(LibvirtConfigGuestMemoryBacking, self).format_dom()
> 
>         if self.hugepages:
>             hugepages = etree.Element("hugepages")
>             #for item in self.hugepages:
>             #    hugepages.append(item.format_dom())
>             root.append(hugepages)
> 
> 
> This results in XML that looks like:
> 
>   <memoryBacking>
>     <hugepages/>
>   </memoryBacking>
> 
> 
> And a qemu commandline that looks like
> 
> -mem-prealloc -mem-path /mnt/huge-2048kB/libvirt/qemu

With that there is no guarantee that the huge pages are being allocated
from the NUMA node on which the guest is actually placed by Nova, hence
we did not intend to support that.

> Instead of commenting out those lines, perhaps it would make sense to wrap
> them inside a check for a new MIN_QEMU_NUMA_HUGEPAGES_VERSION or similar?
> Even better would be to actually check whether the available qemu supports
> numa, since at least one major distro has the right qemu version but doesn't
> compile in numa support.

There's no straightforward reliable way for Nova to detect that upfront
beyond the version number check it has. IMHO that QEMU should just be
rebuilt to enable the NUMA feature, since I'm sure it is merely an
oversight on the part of the maintainer not an intentionale decision.

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