'hw:cpu_thread_policy=prefer' misbehaviour

[Sergey Nikitin]

'hw:cpu_thread_policy=prefer' allocates vCPUs in pairs of sibling threads properly. An odd number of vCPUs will allocate pairs and a single one. That single one should not be isolated. So 20 available threads, shall be able to allocate 4 VMs of 5 vCPUs. When booting up the third VM, it is giving an error.

More information in upstream bug: https://bugs.launchpad.net/nova/+bug/1578155

[Fuel Devops McRobotson (fuel-devops-robot)]

Fix proposed to branch: 9.0/mitaka
Change author: Stephen Finucane <email address hidden>
Review: https://review.fuel-infra.org/30505

[Alexander Rubtsov (arubtsov)]

sla2 for 9.0-updates

[Fuel Devops McRobotson (fuel-devops-robot)]

Reviewed: https://review.fuel-infra.org/30505
Submitter: Pkgs Jenkins <email address hidden>
Branch: 9.0/mitaka

Commit: 835adb75a60be33b187e3192ec8da4e00d0e78b4
Author: Stephen Finucane <email address hidden>
Date: Mon Feb 6 10:06:13 2017

Allow linear packing of cores

Given the following single-socket, four-core, HT-enabled CPU topology:

   +---+---+ +---+---+ +---+---+ +---+---+
   | x | x | | x | | | x | | | | |
   +---+---+ +---+---+ +---+---+ +---+---+
     1 4 2 5 3 6 4 7

Attempting to boot an instance with four cores and no explicit
'cpu_thread_policy' should be successful, with cores 5,6,4,7 used.
However, the current implementation of this implicit policy attempts to
fit the same number of instance cores onto each host CPU. For example,
a four core instance would result in either a 2*2 layout (two instance
cores on each of two host CPUs), or a 1*4 layout (one instance core on
each of four host CPUs). This may be correct behavior *where possible*,
but if this is not possible then any and all cores should be used.

Resolve this issue by adding a fallthrough case, whereby if the
standard fitting policy fails, a linear assignment is used to properly
fit the instance cores.

Closes-bug: #1662130

Change-Id: I73f7f771b7514060f1f74066e3dea1da8fe74c21
(cherry picked from commit 8361d8d6c315bb3ae71c3ff0147f7d5156bc46f3)

[TatyanaGladysheva (tgladysheva)]

Verified on 9.2-mu1 updates.

Environment:
1 controller + 1 compute node
Parameters of every node:
  NUMA topology: 1 NUMA node
  Id 0
  CPU IDs 0, 6, 1, 7, 2, 8, 3, 9, 4, 10, 5, 11
  Memory 31.4 GB
  Nova CPU pinning = 10

Steps to verify:
1. Creating a flavor with 5 VCPUs:
nova flavor-create pinning auto 1024 10 5
nova flavor-key pinning set hw:cpu_policy=dedicated
nova flavor-key pinning set hw:cpu_thread_policy=prefer
nova flavor-key pinning set hw:numa_nodes=1

2. Booting up simple VMs:
nova boot testPin1 --flavor pinning --image cirros --nic net-id=$NET_ID
nova boot testPin2 --flavor pinning --image cirros --nic net-id=$NET_ID

Actual resuls:
Before the fix:
The first VM testPin1 is up & running with flavor 'pinning'.
The second VM testPin2 fails at scheduling.

After the fix:
Both VMs testPin1 and testPin2 are up & running with flavor 'pinning'.