← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1590091] Re: bug in handling of ISOLATE thread policy

 

*** This bug is a duplicate of bug 1550317 ***
    https://bugs.launchpad.net/bugs/1550317

** This bug has been marked a duplicate of bug 1550317
   'hw:cpu_thread_policy=isolate' does not schedule on non-HT hosts

-- 
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/1590091

Title:
  bug in handling of ISOLATE thread policy

Status in OpenStack Compute (nova):
  New

Bug description:
  I'm running stable/mitaka in devstack.  I've got a small system with 2
  pCPUs, both marked as available for pinning.  They're two cores of a
  single processor, no threads.  "virsh capabilities" shows:

            <cpus num='2'>
              <cpu id='0' socket_id='0' core_id='0' siblings='0'/>
              <cpu id='1' socket_id='0' core_id='1' siblings='1'/>
            </cpus>

  It is my understanding that I should be able to boot up an instance
  with two dedicated CPUs and a thread policy of ISOLATE, since I have
  two physical cores and no threads.  (Is this correct?)

  Unfortunately, the NUMATopology filter fails my host.  The problem is
  in _pack_instance_onto_cores():

      if (instance_cell.cpu_thread_policy ==
              fields.CPUThreadAllocationPolicy.ISOLATE):
          # make sure we have at least one fully free core
          if threads_per_core not in sibling_sets:
              return

          pinning = _get_pinning(1,  # we only want to "use" one thread per core
                                 sibling_sets[threads_per_core],
                                 instance_cell.cpuset)

  
  Right before the call to _get_pinning() we have the following:

  (Pdb) instance_cell.cpu_thread_policy
  u'isolate'
  (Pdb) threads_per_core
  1
  (Pdb) sibling_sets 
  defaultdict(<type 'list'>, {1: [CoercedSet([0, 1])], 2: [CoercedSet([0, 1])]})
  (Pdb) sibling_sets[threads_per_core]
  [CoercedSet([0, 1])]
  (Pdb) instance_cell.cpuset
  CoercedSet([0, 1])

  In this code snippet, _get_pinning() returns None, causing the filter
  to fail the host.  Tracing a bit further in, in _get_pinning() we have
  the following line:

          if threads_no * len(sibling_set) < len(instance_cores):
              return

  Coming into this line of code the variables look like this:

  (Pdb) threads_no
  1
  (Pdb) sibling_set
  [CoercedSet([0, 1])]
  (Pdb) len(sibling_set)
  1
  (Pdb) instance_cores
  CoercedSet([0, 1])
  (Pdb) len(instance_cores)
  2

  So the test evaluates to True, and we bail out.

  I don't think this is correct, we should be able to schedule on this
  host.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1590091/+subscriptions


References