Only using huge page may filter the usable host

Bug #1444232 reported by zhangtralon
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Invalid
Low
zhangtralon

Bug Description

when only using huge page parameter without numa to create vms, the current code can generate an instance numatopology with a numa cell.

the solution will filter some hosts which meet the
need of huge page but no numa.

I think that binding the huge page with numa so closely is unreasonable.

description: updated
Changed in nova:
assignee: nobody → zhangtralon (zhangchunlong1)
Changed in nova:
status: New → Confirmed
importance: Undecided → Low
description: updated
Revision history for this message
Nikola Đipanov (ndipanov) wrote :

Hmmm are you sure that this is correct - in the current libvirt implementation - even single node hosts will report a topology (with a single cell) so I am not sure this will filter any hosts out unless they are running a very old version of libvirt which would not support large pages anyway.

Changed in nova:
status: Confirmed → Incomplete
Revision history for this message
Daniel Berrange (berrange) wrote :

Yep, every single compute host should always be reporting at least a single NUMA node containing all CPUs/RAM, so if a guest has only requested hugepages, the NUMA logic shouldn't cause hosts to be filtered out. So I don't see any reason to separate numa/hugepage scheduling for that case

Revision history for this message
zhangtralon (zhangchunlong1) wrote :

yeah, Daniel and Nikola, you are right.
Before, I find no numa in a host by the numactl --hardware, so I think that there may be no numa topo.
I made the following test, and find that the libvirt return a numa even if the value from the numactl is zero.
thanks.

root@tralon-Vostro-1400:~# virsh --version
1.2.2
root@tralon-Vostro-1400:~# numactl --hardware
available: 0 nodes ()
root@tralon-Vostro-1400:~# virsh capabilities
<capabilities>

  <host>
    <uuid>44454c4c-3500-1039-8038-b4c04f433258</uuid>
    <cpu>
      <arch>i686</arch>
      <model>n270</model>
      <vendor>Intel</vendor>
      <topology sockets='1' cores='2' threads='1'/>
      <feature name='lahf_lm'/>
      <feature name='lm'/>
      <feature name='pdcm'/>
      <feature name='xtpr'/>
      <feature name='cx16'/>
      <feature name='tm2'/>
      <feature name='est'/>
      <feature name='vmx'/>
      <feature name='ds_cpl'/>
      <feature name='dtes64'/>
      <feature name='pbe'/>
      <feature name='tm'/>
      <feature name='ht'/>
      <feature name='ss'/>
      <feature name='acpi'/>
      <feature name='ds'/>
      <feature name='pse36'/>
    </cpu>
    <power_management>
      <suspend_mem/>
      <suspend_disk/>
      <suspend_hybrid/>
    </power_management>
    <migration_features>
      <live/>
      <uri_transports>
        <uri_transport>tcp</uri_transport>
      </uri_transports>
    </migration_features>
    <topology>
      <cells num='1'>
        <cell id='0'>
          <memory unit='KiB'>3106852</memory>
          <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>
        </cell>
      </cells>
    </topology>
    <secmodel>
      <model>apparmor</model>
      <doi>0</doi>
    </secmodel>
    <secmodel>
      <model>dac</model>
      <doi>0</doi>
      <baselabel type='kvm'>+117:+126</baselabel>
      <baselabel type='qemu'>+117:+126</baselabel>
    </secmodel>
  </host>

</capabilities>

Changed in nova:
status: Incomplete → Invalid
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.