[openstack-hpc] NUMA config

Blair Bethwaite blair.bethwaite at gmail.com
Wed May 6 03:17:28 UTC 2015


Daniel,

Thank you for the detailed response. I take your point on the settings
that have a direct effect on resource utilisation etc, and thanks for
the info about the ongoing work!

Cheers,

On 30 April 2015 at 19:38, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Thu, Apr 30, 2015 at 11:21:26AM +1000, Blair Bethwaite wrote:
>> Thanks Daniel,
>>
>> I'll fix that, need to try my hand at doc patches.
>
> I've actually sent a patch for that late last night already
>
>    https://review.openstack.org/#/c/178773/
>
>
>> Whilst I've got your attention, any comment on my aside about it
>> seeming odd from userland perspective that these (and similar
>> tunables) are controlled through flavor/image extra specs?
>> "Does anyone else find it strange that all these options are designed
>> to be flavor and/or image extra specs rather than providing a
>> mechanism to set them on instance boot (e.g. hints). I think the
>> relationship between flavors or images and such tunables is tenuous at
>> best, why should I need multiple versions of what is otherwise the
>> same image or flavor in order to ask for e.g. CPU pinning or Qemu
>> Guest Agent, these are per instance tunables/variables."
>
> Ok, so first of all, NUMA, strict cpu pinning and huge page
> configuration policies have a direct impact on compute host
> utilization. The cloud admin has to setup host aggregates to
> make proper use of dedicated cpu pinning & huge pages, and
> these imply no use of over commit. Given that CPU & RAM Is
> a finite resource, the cloud admin must retain a way to
> prevent users from accessing cpu pinning & huge pages features.
>
> The only mechanism to prevent such usage is to set properties
> on the flavour - the flavours are the core access control
> mechanism in Nova for resource usage. So the cloud admin can
> setup flavours which allow or deny use of these features.
> This is what I'd expect to be the usage pattern for public
> cloud where permissioning is very important.
>
> To make it more useful for private cloud though, we allow
> all the properties to be set at the image level, /provided/
> they don't conflict with anything set at the flavour level.
> ie the flavour settings always take priority, to prevent
> tenants violating cloud admin's controls.
>
> That is how things stand today. There *is* however a more
> general goal to enhance the Nova boot API, so that any
> image property can also be specified at time you boot the
> instance. This will apply not just for NUMA/CPU/hugepags
> things, but for absolutely any setting that is currently
> valid against the image.
>
> Before we can do that though, Nova people wanted us to
> better specify exactly what we support for image properties
> To that end I've actually been working on a change to make
> a formally defined object listing all known image properties:
>
>   https://review.openstack.org/#/c/76234/28/nova/objects/image_meta_props.py
>
> Once we get this approved, then we can look at the enhancement
> for the nova boot API. I'm not going to promise this will happen
> in Liberty release cycle, but it /is/ something we want to get
> done for Nova.
>
> 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 :|



-- 
Cheers,
~Blairo



More information about the OpenStack-HPC mailing list