Small pages memory are not take into account when not explicitly requested

Bug #1439247 reported by Sahid Orentino on 2015-04-01
This bug affects 4 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)

Bug Description

Guests using small pages (as default) on compute node are not take into account when calculating available small pages memory [1] - Consequence when booting instance with an explicitly small pages request the compute of available resources is corrupted.

In order to fix the issue two solutions are able.

Associate to every guest a NUMA topology and set the default page_size to MEMPAGES_SMALL when nothing has been requested by user. ** This also implies when using libvirt the default option of virt-type should be KVM **

A small couple of change are needed in
- make the method 'numa_get_constraints' to return NUMATopology in all cases.
- make the method ' _numa_get_pagesize_constraints' to return MEMPAGES_SMALL instead of None when nothing is requested.

Disallow to request a memory page size small, means remove all of the code which handle that case since the information reported to the host are not correctly updated and let the default behavior handle that case.


Sean Dague (sdague) on 2015-04-01
tags: added: numa
Changed in nova:
status: New → Confirmed
Nikola Đipanov (ndipanov) wrote :

So some comments regarding 1/

* I am not sure if we want to make NUMA topology (even if single cell) exposed to every instance without a way to turn it off. There may be guest OS concerns around that for the libvirt case.
* The NUMA information makes no sense at this point for other drivers, some of which may never implement it.

Based on that it seems to me that a cleaner approach is to keep the NUMA qualities of instances optional

2/ Seems like a better approach to me - as for how to keep the smallest page size information in sync - two things come to mind: either don't report the smalles size at all, or make sure that resource tracker considers it and tracks it even for non-numa instances. I slightly prefer the first option

Change abandoned by Michael Still (<email address hidden>) on branch: master
Reason: This patch is very old and appears to not be active any more. I am therefore abandoning it to keep the nova review queue sane. Feel free to restore the change when you're actively working on it again.

Sujitha (sujitha-neti) wrote :

This has not been updated in a long time. Moving it to Unassinged.

Please assign it to yourself and set to in progress if you plan on working on it.

Changed in nova:
assignee: sahid (sahid-ferdjaoui) → nobody
aishwarya (bkaishwarya) on 2017-01-06
Changed in nova:
assignee: nobody → aishwarya (bkaishwarya)
aishwarya (bkaishwarya) wrote :

can you please specify the reproduction steps of this bug.Thanks in advance.

Change abandoned by sahid (<email address hidden>) on branch: master

Sean Dague (sdague) on 2017-06-23
Changed in nova:
assignee: aishwarya (bkaishwarya) → nobody
Chris Friesen (cbf123) wrote :

There is some useful discussion under bug 1792985 which has been marked as a dupe of this bug.

Currently it's still not safe to schedule numa-topology and non-numa-topoology on the same compute node because instances with no numa topology can "float" over the whole compute node, which means we have no way of knowing where the memory comes from and therefore can't possibly accurately track memory consumption per NUMA node.

I think it's a cop-out to say "don't schedule numa-topology and non-numa-topology instances on the same compute node". I mean, the way the code is written currently its not safe, but I think we *should* try to make it safe.

Specifically for edge scenarios, we may only have a small number of compute nodes (sometimes just one or two) and so any host-aggregate-based solution doesn't really work. We need to be able to have these things co-exist on a single compute node.

Specifically for 4K memory, this means either disabling "strict" NUMA affinity, or else restricting floating instances to a single NUMA node.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers