[openstack-dev] [nova] NUMA, huge pages, and scheduling

Jay Pipes jaypipes at gmail.com
Thu Jun 23 22:27:39 UTC 2016

On 06/22/2016 01:56 PM, Paul Michali wrote:
> I did have a question about the current implementation as described by
> 292499, 324379, and 292500.
> Looking at the code, when a NUMAPagesTopology object is create, a new
> parameter is passed for the "reserved" pages. This reservation comes
> from a dictionary, which is populated at LIbvirtDriver init time, via
> grabbing the multi-string configuration settings from nova.conf. Because
> the object's API is changed, a version change is required.
> Is it possible to, instead of adding a new argument to reduce the
> "total" argument (Ian Wells suggested this to me on a patch I had), by
> the number of reserved pages from the config file? This would prevent
> the need to alter the object's API.  So, instead of:
>                  mempages = [
>                      objects.NUMAPagesTopology(
>                          size_kb=pages.size,
>                          total=pages.total,
>                          used=0,
>                          reserved=_get_reserved_memory_for_cell(
>                              self,cell.id <http://cell.id>, pages.size))
>                      for pages in cell.mempages]
> Do something like this...
>   mempages = [
> objects.NUMAPagesTopology( size_kb=pages.size, used=0, total=pages.total
> - _get_reserved_memory_for_cell( self, cell.id <http://cell.id>,
> pages.size)) for pages in cell.mempages]
> If we do this, would it avoid issues with back porting the change?

No, that would cause anyone who upgraded to Mitaka to immediately have 
the total column contain incorrect data... you would essentially have a 
double-reserve calculation.


More information about the OpenStack-dev mailing list