Tensorflow(libtensorflow)报指令集与处理器不兼容

最近连续在多个项目上接收到Tensorflow与环境不兼容问题的报告。

主要现象

1. 在一个新部署或者升级的环境上，服务尝试启动；

2. 正常执行过程中，服务加载模型，标准错误中输出一行错误信息后服务停止。

错误信息：

tensorflow/core/platform/cpu_feature_guard.cc:36] The TensorFlow library was compiled to use SSE4.1 instructions, but these aren't available on your machine

目前至少有三个出现错误的机器，CPU分别为：

• Intel Xeon E5 4640

• AMD Opteron 6376

• Intel Xeon Gold 6130

可是，根据Intel和AMD的硬件信息，以上CPU都已经支持 SSE4.1，但TensorFlow都提示不支持，因此不是硬件不符合要求造成的。那问题出在哪里呢？

问题排查

首先，肯定是确认Tensorflow的检测本身是否有问题。

首先根据代码提示查看了Tensorflow源代码。检查CPU指令集支持的代码位于tensorflow / core / platform /cpu_info.cc 中Initialize()方法。

    // To getgeneral information and extended features we send eax = 1 and
    // ecx = 0 tocpuid. The response is returned in eax,ebx, ecx and edx.
    // (See Intel 64and IA-32 Architectures Software Developer's Manual
    // Volume 2A:Instruction Set Reference, A-M CPUID).
    GETCPUID(eax, ebx, ecx, edx, 1, 0);
  
    cpuid->model_num_ = static_cast((eax >> 4) & 0xf);
    cpuid->family_ = static_cast((eax >> 8) & 0xf);

…….

    cpuid->have_sse2_ = (edx >> 26) & 0x1;
    cpuid->have_sse3_ = ecx & 0x1;
    cpuid->have_sse4_1_ = (ecx >> 19) & 0x1;
    cpuid->have_sse4_2_ = (ecx >> 20) & 0x1;
    cpuid->have_sse_ = (edx >> 25) & 0x1;
    cpuid->have_ssse3_ = (ecx >> 9) & 0x1;
    cpuid->have_hypervisor_ = (ecx >> 31) & 1;

其中，GETCPUID(a, b, c,d, eax, ecx)是用gcc汇编实现的：

#define GETCPUID(a, b, c, d, a_inp, c_inp) \
  asm("mov %%rbx, %%rdi\n"                 \
      "cpuid\n"                            \
      "xchg %%rdi, %%rbx\n"                \
      : "=a"(a), "=D"(b), "=c"(c), "=d"(d) \
      : "a"(a_inp), "2"(c_inp))
#endif

从Tensorflow的代码上看是使用CPUID指令获取CPU信息的，如果是在真实设备上执行的话，这样没有问题。

然后，我检查了cpuinfo。

根据检查，这些环境cpuinfo的flags都没有SSE4.1，因此有必要研究cpuinfo的信息生成方式。

Stack Overflow上面的这个问题介绍了Linux内核获取CPU信息的方法。Linux内核也使用CPUID指令获取CPU信息，

通过查看Linux x86源码，在arch/x86/kernel/cpu/proc.c 中，flags 是按如下方式生成的。

    seq_printf(m,"flags\t\t:");
    for (i = 0; i < 32*NCAPINTS;i++)
       if (cpu_has(c, i) && x86_cap_flags[i] !=NULL)
           seq_printf(m, " %s", x86_cap_flags[i]);

以上代码表明，Linux内核也使用CPUID指令获取CPU信息，但是对自己不理解的CPUID信息不会显示在 flags中，即CPUID不显示不表示该指令集不可用，可能只是内核没有支持。

问题排查的前景突然暗淡了下来。

这时候，我又再次检查了cpuinfo。突然有个发现，目前所有出现问题的机器均运行于虚拟机上（cpuinfo flags上 有 hypervisor 标识），根据上述排查可以推断，虚拟机虚拟的CPU存在问题。

在查找资料，我看到了以下两条信息：

首先是linux下面最广泛使用的qemu-kvm，大名鼎鼎的OpenStack底层也是它。在Linux-KVM 以及实现层qemu-kvm中，CPU模型（models）定义了哪些主机的CPU功能（features）会被暴露给客户机操作系统。为了在具有不同 CPU 功能的主机之间做安全的迁移，qemu-kvm往往不会将主机CPU的所有功能都暴露给客户机。可以使用-cpu (model),(feature) 指定模拟的CPU特性，也可以直接使用 -cpu host，这样的话会客户机使用和主机相同的 CPU model。

详细的配置可以参考：https://qemu.weilnetz.de/doc/4.2/qemu-doc.html#cpu_005fmodels

其次是VMWare家。在VMWare vCenter中，EVC允许在不同代的CPU之间迁移虚拟机，位于EVC集群中的CPU功能是受到限制的，其中Intel “Merom” Generation (Intel Xeon Core 2) / AMD Opteron Generation 3(以及更早版本)不支持SSE4.1。

详细的信息可以参考：https://kb.vmware.com/s/article/1005764

于是我尝试联系了其中一个客户。

客户生产环境使用H3C CAS虚拟化平台。H3C CAS平台创建虚拟机时可以选择CPU模拟方式，其中Custom模式不支持AES指令集，理论上也不支持邻近的SSE4.1指令集。但是通过修改配置，将CPU改为pass-through可以支持。

于是我们让客户停机，做了修改。问题解决。

结论

最后，我们在部署环境要求上增加了如下的CPU要求：

如果该服务器运行于虚拟机上，则要求QEMU体系的虚拟机下（如OpenStack、H3C CAS及其他基于KMV的定制化云平台等环境），必须确认虚拟机CPU工作模式配置为“定制化模式”或“穿透模式”。

同时我们也编译了仅支持sse3的libtensorflow。