Open Stack

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


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.

Chris