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

这篇具有很好参考价值的文章主要介绍了Tensorflow(libtensorflow)报指令集与处理器不兼容。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

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

主要现象

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

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

错误信息：

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<int>((eax >> 4) & 0xf);
    cpuid->family_ = static_cast<int>((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可以支持。

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