OpenStack对NUMA的支持情况(by quqi99)

最新推荐文章于 2022-02-17 18:04:46 发布

quqi99

最新推荐文章于 2022-02-17 18:04:46 发布

阅读量6k

点赞数

分类专栏： OpenStack Non-Networking 文章标签： power smt numa topology

本文链接：https://blog.csdn.net/quqi99/article/details/50988089

版权

OpenStack Non-Networking 专栏收录该内容

72 篇文章 1 订阅

订阅专栏

作者：张华发表于：2016-03-24
版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明

( http://blog.csdn.net/quqi99 )

理论

vCPU topology, libvirt将第一个vCPU在虚机中视为: 1 socket with 1 core and no hyper-threads. 但有的操作系统的license会限制socket的数目，另外一般地在不同的core上的2个threads的性能会比2个在同相core上的threads的性能要好。
NUMA topology, NUMA节点有自己独立的RAM、Bus、PCI和pCPU sockets, 为一个VM分配cpu及PCI设备时应该尽量分配同一个NUMA节点上的pCPU。
Guest NUMA, 如果一个VM要求的vCPU/RAM/PCIe大于一个NUMA节点所具有的物理pCPU/RAM/PCIe呢？
可划分为多个NUMA节点（hw:numa_nodes=N).
Large pages, CPU支持4k, 2M/4M, 1G的Hugepage模式(page_sizes=(any|small|large)，这时cpu的页表数目会减少提升TLB页表的命中率，但操作系统默认为4k，运行时间长了很难找到连续的大页空间分配。当前Kernel不允许为NUMA节点预留大页，NUMA节点有特定的RAM，也就是说，NUMA节点也有特定的大页。在的NUMA节点有足够的大页空间，有的可能刚好没有了。
Dedicated resource, overcommit_ram=0,overcommit_vcpus=0
KSM(kernel shared memory), 将相同的内存分页进行合并，合并之后若再遇到写就再用CoW打开一份，要能阻止宿主机将特定的内存分页合并。

例如：我的t440p是一个cpu(socket), 双核，开了超线程，4个core id, 所以siblings也是4(一个物理封装中的逻辑cpu个数，只有一个cpu所以是一个物理，然后双核，超线程).

实际操作

Image方式, glance image-update --property hw_numa_nodes=2 hw_numa_cpus.0=0 hw_numa_mem.0=512 hw_numa_cpus.1=0 hw_numa_mem.1=512 image_name
Flavor方式, nova flavor-key flv_name set hw:numa_nodes=2 hw:numa_cpus.0=0 hw:numa_mem.0=512 hw:numa_cpus.1=0 hw:numa_mem.1=512

hw:numa_nodes=NN #guest NUMA node数量
hw:numa_mempolicy=preferred|strict #RAM占用方式
hw:numa_cpus.N=<cpu-list> #guest NUMA node N中的vcpu列表
hw:numa_mem.1=<ram-size> #guest NUMA node N中的RAM大小
hw:cpu_thread_policy=prefer|isolate|require
hw:cpu_policy=shared|dedicated

libvirt.xml

<cputune>   
  /** pin vCPU to pCPU set in cputune **/
  <vcpupin vcpu="0" cpuset="4-7,12-15"/>         
</cputune>   
/** expoert guest numa in cpu/numa **/ 
<cpu>   
   <topology sockets="2" cores="2" threads="1"/>    
   <numa>   
      <cell id="0" cpus="0-1" memory="1048576"/>    
   </numa>   
</cpu>

nova-scheduler

NUMATopologyFilter

一些命令

hua@node1:~$ sudo virsh nodeinfo
CPU model:           x86_64
CPU(s):              4
CPU frequency:       3348 MHz
CPU socket(s):       1
Core(s) per socket:  4
Thread(s) per core:  1
NUMA cell(s):        1
Memory size:         32753068 KiB

hua@node1:~$ sudo virsh freecell 0
0: 9974312 KiB

附件 - Power SMT

Power 8有一个SMT特性，即多线程的并发改为一个核内多个指令的并发从而提升性能，但是KVM Power版本却不支持SMT，所以需要将SMT关闭，这样造成性能下降，这样pacemaker将会报这种错”Sep 22 06:52:35 juju-b209b8-4-lxd-2 crmd[122100]: notice: High CPU load detected“，从而造成如glance service的vip不work了也就无法ping了。其实，即使SMT=off (echo off > /sys/devices/system/cpu/smt/control)也是可以利offline的核的，即采用这个网页（https://www.ibm.com/developerworks/community/blogs/fe313521-2e95-46f2-817d-44a4f27eba32/entry/enabling_smt_on_powerkvm_guests?lang=en）的方法：

nova针对一个虚机使用8个vcpu有下列三种配置方法：

1) By default in nova
<vcpu placement='static'>8</vcpu>
<cpu>
<topology sockets='8' cores='1' threads='1'/>
...
</cpu>

2) 4 threads
<vcpu>8</vcpu>
<cpu>
<topology sockets='1' cores='2' threads='4'/>
...
</cpu>

3) 8 threads
<vcpu>8</vcpu>
<cpu>
<topology sockets='1' cores='1' threads='8'/>
...
</cpu>

如想要配置成上面的2）的话，可以：

openstack flavor set <FLAVOR_UUID> \
--vcpus 8 \
--property hw:cpu_sockets=1 \
--property hw:cpu_cores=2 \
--property hw:cpu_threads=4
配置成上面的3）的话，可以：

openstack flavor set <FLAVOR_UUID> \
--vcpus 8 \
--property hw:cpu_sockets=1 \
--property hw:cpu_cores=1 \
--property hw:cpu_threads=8

Power8在设计上是有缺陷的, 它需要先关闭SMT, 然后在KVM里又可以使用offline CPU, Power9则修复了这个问题, 见: https://www.linux-kvm.org/images/7/77/01x09a-KVMPower.pdf

另外, 因为SMT关闭了, 当Power8上的KVM未使用上面拓扑时一个使用8个vcpu的虚机占了8个核而不是一个核上的8线程, 这样无形中CPU数少了8倍. 这个机器如果不光是KVM还有mysql的话mysql也存在这种情况, 这样使用perf查看时会看到mysql与kvm并没有哪个特别宽, 都差不多分布比较均匀, 这样反而证明了整体性能需要提升. mysql因为是openstack的底层服务无法使用上面的拓扑使用多线程, 所以最好不要将mysql和kvm安装在一块.

再说说sbiblings

siblings指一个物理cpu上的cpu, 下面的设置是两个cell两个物理cpu，一个物理cpu是32个core超线程是2故共32个thread

NUMA node0 CPU(s):   0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52,54,56,58,60,62
NUMA node1 CPU(s):   1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47,49,51,53,55,57,59,61,63
CPU(s):              64
On-line CPU(s) list: 0-63
Thread(s) per core:  2
Core(s) per socket:  16
Socket(s):           2
NUMA node(s):        2

nova中看到的pcpuset与siblings如下：

pcpuset=set([8,10,12,14,16,18,20,22,24,26,28,30,40,42,44,46,48,50,52,54,56,58,60,62])
siblings=[set([16,48]),set([10,42]),set([54,22]),set([46,14]),set([12,44]),set([20,52]),set([26,58]),set([28,60]),set([62,30]),set([18,50]),set([8,40]),set([24,56])]

当设置cpu_thread_policy='isolate'时，意味着不用thread只用真正的core.
因为siblings对象的引入的目的就是为了无论服务器是否开启了超线程，Nova 同样能够支持物理CPU绑定的功能。
这样，当一个虚机使用了[8, 10, 12, 16, 18, 20, 24, 26, 28, 46, 54, 62]这些cpu的话，pinned_cpus会如下：

pinned_cpus=set([8,10,12,14,16,18,20,22,24,26,28,30,40,42,44,46,48,50,52,54,56,58,60,62])

所以用thread的话就配置hw:cpu_thread_policy=require, 用core的话就用cpu_thread_policy='isolate'.
而且如果emulator也用了isolate的话（hw:emulator_threads_policy='isolate'）, not only will it not allow a sibling but it will also require all pcpu to be
available on the same numa node.

也参考：https://blog.csdn.net/quqi99/article/details/51993512

参考

https://wiki.openstack.org/wiki/VirtDriverGuestCPUMemoryPlacement
https://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/virt-driver-cpu-pinning.html
http://blog.csdn.net/canxinghen/article/details/41810241
https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/virt-driver-cpu-thread-pinning.html
http://docs.openstack.org/developer/nova/testing/libvirt-numa.html
https://www.berrange.com/posts/2010/02/12/controlling-guest-cpu-numa-affinity-in-libvirt-with-qemu-kvm-xen/
https://review.openstack.org/#/c/140290/
http://slideplayer.com/slide/4868412/