CPU topology does not honour cpu_max_threads when NUMA topology is used

Bug #1471187 reported by Daniel Berrange
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
High
Daniel Berrange

Bug Description

Consider a flavour with 4 vcpus, and image property hw:cpu_threads==2. Now the NUMA topology may prefer a thread count of 4, but best of the thread preference set, the guest will end up with 2 sockets, 1 core and 2 threads.

Now consider a flavour with 4 vcpus, and image property hw:cpu_max_threads==2. Now the NUMA topology may prefer a thread count of 4, but best of the thread limit is set, so the guest should again end up with 2 sockets, 1 core and 2 threads.

The current code in nova.virt.hardware._get_possible_cpu_topologies() is not honouring the cpu_max_threads setting in this scenario though, so the guest ends up with 1 socket, 1 core and 4 threads. This violates the cpu_max_threads setting.

Meanwhile if the vCPU count is 6 and the NUMA topology prefers a thread count of 4, then the code is actually incapable of coming up with a valid topology because it only considers topologies with an exact thread count of 4 and 4 does not divide into 6.

nova.exception.ImageVCPULimitsRangeImpossible: Requested vCPU limits 6:6:6 are impossible to satisfy for vcpus count 6

which is clearly a bogus error as you can easily satisfy that with 6:1:1, 1:6:1, 1:1:6, 2:1:3, 2:3:1, 3:2:1, 3:1:2, 1:2:3, 1:3:2, so it should have picked 2:1:3, as that has thread count closest matching the NUMA topology and the maximum socket count.

Changed in nova:
importance: Undecided → High
assignee: nobody → Daniel Berrange (berrange)
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (master)

Reviewed: https://review.openstack.org/198312
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=f396826314b9f37eb57151f0dd8a8e3b7d8a8a5c
Submitter: Jenkins
Branch: master

commit f396826314b9f37eb57151f0dd8a8e3b7d8a8a5c
Author: Daniel P. Berrange <email address hidden>
Date: Fri Jul 3 11:29:03 2015 +0100

    virt: fix picking CPU topologies based on desired NUMA topology

    The _get_possible_cpu_topologies() method is intended to return
    a list of CPU topologies that honour the constraints set by the
    cpu_max_sockets, cpu_max_cores & cpu_max_threads image/flavour
    properties. In

      commit 770ab8eeb72b184ac6164aeabb89c4bf45f938a9
      Author: Nikola Dipanov <email address hidden>
      Date: Mon Dec 8 14:45:48 2014 +0100

        Make get_best_cpu_topology consider NUMA requested CPU topology

    the code was changed so that the desired thread count from the
    NUMA topology was passed in. Unfortunately the logic implemented
    was flawed because it while the cpu_threads preferred threads
    count was honour, it would not honour the cpu_max_threads
    value.

    So if you have

      vcpus=4
      hw_cpu_threads = 2
      NUMA threads == 4

    It would return CPU topologies with 2 threads, but if you had

      vcpus=4
      hw_cpu_max_threads = 2
      NUMA threads == 4

    then it would return CPU topologies with 4 threads, which
    violates the users request.

    If you had a vcpu count not a multiple of the NUMA threads

      vcpus=6
      NUMA threads = 4

    then it would be incapable of determining any topology
    as it only looked for exact matching threads and 4 does
    not divide into 6.

    The _threads_requested_by_user() method has a typo in it
    causing it to look for whether 'cpu_maxthreads' exists,
    but correcting that to 'cpu_max_threads' does not do
    anything to fix the actual behaviour, as the max threads
    value is never acted upon.

    If we clamped the 'min_requested_threads' value calculated
    in _get_desirable_cpu_topologies() to cpu_max_threads, the
    code still doesn't work, as the max threads count may not
    actually be a multiple of the vCPU count. We need to
    consider which topologies have a threads count that is
    closest to the desired NUMA threads, but not exceeding
    the max threads count.

    To solve this properly we revert the changes to the
    _get_possible_cpu_topologies() method, so that it only
    ever considers the user provided max sockets/cores/threads
    value from the image/flavour as it originally did.

    We then introduce a _filter_for_numa_threads() method
    which filters the list of possible topologies, to those
    which most closely match the desired number of threads
    from the NUMA topology.

    Finally we do the sorting based on the preferred
    topologies defined by the cpu_sockets/cores/threads
    image/flavour properties

    Closes-bug: #1471187
    Change-Id: I05f246401526170acb61370ee51355226366a4c9

Changed in nova:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in nova:
milestone: none → liberty-2
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in nova:
milestone: liberty-2 → 12.0.0
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.