[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