[MU] Random NUMA cell selection can leave NUMA cells unused
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mirantis OpenStack |
Invalid
|
Medium
|
Alexey Stupnikov |
Bug Description
The bug description below was copied from the original bug: https:/
I'm reporting the bug to get it included into maintenance updates.
---------------
NUMA cell overcommit can leave NUMA cells unused
When no NUMA configuration is defined for the guest (no flavor extra specs),
nova identifies the NUMA topology of the host and tries to match the cpu
placement to a NUMA cell ("cpuset").
The cpuset is selected randomly.
pin_cpuset = random.
However, this can lead to NUMA cells not being used.
This is particular noticeable when the flavor as the same number of vcpus
as the host NUMA cells and in the host CPUs are not overcommit (cpu_allocation
###
Particular use case:
Compute nodes with the NUMA topology:
<VirtNUMAHostTo
No CPU overcommit: cpu_allocation_
Boot instances using a flavor with 8 vcpus.
(No NUMA topology defined for the guest in the flavor)
In this particular case the host can have 2 instances. (no cpu overcommit)
Both instances can be allocated (random) with the same cpuset from the 2 options:
<vcpu placement='static' cpuset=
<vcpu placement='static' cpuset=
As consequence half of the host CPUs are not used.
###
How to reproduce:
Using: nova 2014.2.2
(not tested in trunk however the code path looks similar)
1. set cpu_allocation_
2. Identify the NUMA topology of the compute node
3. Using a flavor with a number of vcpus that matches a NUMA cell in the compute node,
boot instances until fill the compute node.
4. Check the cpu placement "cpuset" used by the each instance.
Notes:
- at this point instances can use the same "cpuset" leaving NUMA cells unused.
- the selection of the cpuset is random. Different tries may be needed.
Changed in mos: | |
importance: | Undecided → Medium |
status: | New → Confirmed |
Changed in mos: | |
assignee: | MOS Maintenance (mos-maintenance) → Alexey Stupnikov (astupnikov) |
I have set bug's status to invalid, since it is already fixed in MOS7.0 (openstack- ci/fuel- 7.0/2015. 1.0 branch).