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

Paul Michali pc at michali.net
Wed Jun 22 17:56:54 UTC 2016


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, 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, pages.size)) for pages in
cell.mempages]
If we do this, would it avoid issues with back porting the change?

Thanks!

PCM


On Wed, Jun 15, 2016 at 5:52 PM Matt Riedemann <mriedem at linux.vnet.ibm.com>
wrote:

> On 6/15/2016 3:10 PM, Paul Michali wrote:
> > Is the plan to back port that change to Mitaka?
> >
> > Thanks,
> >
> > PCM
> >
> >
> > On Wed, Jun 15, 2016 at 1:31 PM Matt Riedemann
> > <mriedem at linux.vnet.ibm.com <mailto:mriedem at linux.vnet.ibm.com>> wrote:
> >
> >     On 6/14/2016 3:09 PM, Jay Pipes wrote:
> >     >
> >     > Yes. Code merged recently from Sahid does this:
> >     >
> >     > https://review.openstack.org/#/c/277422/
> >     >
> >     > Best,
> >     > -jay
> >     >
> >
> >     That was actually reverted out of mitaka:
> >
> >     https://review.openstack.org/#/c/292290/
> >
> >     The feature change that got into newton was this:
> >
> >     https://review.openstack.org/#/c/292499/
> >
> >     Which was busted, and required:
> >
> >     https://review.openstack.org/#/c/324379/
> >
> >     Well, required as long as you want your compute service to start. :)
> >
> >     And no, we aren't backporting these, especially to liberty which is
> >     security / critical fix mode only now.
> >
> >     --
> >
> >     Thanks,
> >
> >     Matt Riedemann
> >
> >
> >
>  __________________________________________________________________________
> >     OpenStack Development Mailing List (not for usage questions)
> >     Unsubscribe:
> >     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >     <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> No, it's really a feature.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160622/648389d3/attachment.html>


More information about the OpenStack-dev mailing list