Public bug reported: Calculating CPU pinning for an instance for the host with hyperthreading fails in certain cases. Most notably when the instance has an odd number of CPUs, due to a bug in the logic we might either fail to pin entirely or end up avoiding siblings by accident, although the default policy should be to prefer them (which is what happens when we have an even number of CPUs).
Consider a host with CPUs [(0, 3), (1, 4), (2, 5)] (brackets denote thread siblings). Instance with 5 CPUs would fail to get fitted onto this host even though it's clear that it's absolutely possible to fit that instance on there. Another unexpected result happens when we have a host [[0, 8], [1, 9], [2, 10], [3, 11], [4, 12], [5, 13], [6, 14], [7, 15]] and a 5 CPU instance. In this case an instance with 5 CPUs would get pinned as follows (instance cpu -> host cpu): [(0 -> 0), (1 -> 1), (2 -> 2), (3 -> 3), (4 -> 4)] which is wrong since the default for instances with an even number of CPUs would be to prefer sibling CPUs. After inspecting the fitting logic code: https://github.com/openstack/nova/blob/b0013d93ffeaed53bc28d9558def26bdb7041ed7/nova/virt/hardware.py#L653 I also noticed that we would consult the existing topology of the instance NUMA cell when deciding on the proper way to fit instance CPUs onto host. This is actually wrong after https://review.openstack.org/#/c/198312/. We don't need to consider the requested topology in the CPU fitting any more as the code that decides on the final CPU topology takes all of this into account. ** Affects: nova Importance: Medium Status: New ** Tags: numa -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1501358 Title: cpu pinning on the host that has siblings does not work properly in some cases (instance with odd CPUs) Status in OpenStack Compute (nova): New Bug description: Calculating CPU pinning for an instance for the host with hyperthreading fails in certain cases. Most notably when the instance has an odd number of CPUs, due to a bug in the logic we might either fail to pin entirely or end up avoiding siblings by accident, although the default policy should be to prefer them (which is what happens when we have an even number of CPUs). Consider a host with CPUs [(0, 3), (1, 4), (2, 5)] (brackets denote thread siblings). Instance with 5 CPUs would fail to get fitted onto this host even though it's clear that it's absolutely possible to fit that instance on there. Another unexpected result happens when we have a host [[0, 8], [1, 9], [2, 10], [3, 11], [4, 12], [5, 13], [6, 14], [7, 15]] and a 5 CPU instance. In this case an instance with 5 CPUs would get pinned as follows (instance cpu -> host cpu): [(0 -> 0), (1 -> 1), (2 -> 2), (3 -> 3), (4 -> 4)] which is wrong since the default for instances with an even number of CPUs would be to prefer sibling CPUs. After inspecting the fitting logic code: https://github.com/openstack/nova/blob/b0013d93ffeaed53bc28d9558def26bdb7041ed7/nova/virt/hardware.py#L653 I also noticed that we would consult the existing topology of the instance NUMA cell when deciding on the proper way to fit instance CPUs onto host. This is actually wrong after https://review.openstack.org/#/c/198312/. We don't need to consider the requested topology in the CPU fitting any more as the code that decides on the final CPU topology takes all of this into account. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1501358/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
