Question

我有兴趣评估运行CentOS的Linux机器上SMI处理的行为（延迟，频率），并用于（非常）软实时应用程序。

推荐使用哪些工具（针对CentOS的hwlatdetect？），以及最佳解决方案是什么？
如果没有适合CentOS的好工具，我认为安装一个由于底层硬件/ BIOS相同，同一台机器上的不同操作系统应该产生相同的结果？
这些参数的球场数据是否有任何来源。

这些机器是X86_64架构，运行CentOS 6.4（内核2.6.32-358.23.2.el2.centos.plus.x86_64。）

Answer 1

SMI在正常运行期间肯定会发生。我的家用台式机在芯片组中启用了芯片组驱动的SMI，每秒一半。由于BIOS驱动的CPU频率扩展方案，我也看到一些服务器每秒两次。但是，有些系统可能会长时间没有发生SMI，所以它真的取决于它。

问题＃1：hwlatdetect是一种检测系统上发生的SMI延迟的选项。 BIOSBITS是另一个选项，它是一个可引导的CD，可以识别SMI是否正在发生。您还可以通过创建在循环中旋转并采用时间戳（使用RDTSC）的内核模块来编写自己的测试。如果您看到两个时间戳读数之间存在较长的间隙，则可以查询CPU MSR 0x34以查看SMI计数器是否递增，这表示发生了SMI。

如果要生成SMI，可以创建一个内核模块，对OUT端口0xb2执行OUT CPU指令，例如：将值0写入此端口。（您也可以通过在写入端口0xB2之前和之后收集时间戳来计时此SMI）。

问题＃2，SMI在操作系统以下的层运行，因此您选择的操作系统不会产生任何影响。

问题3：BIOSBITS建议将SMI延迟保持在150微秒以下。

Answer 2

SMI会将您的系统置于SMM（系统管理模式）模式，这将推迟在SMI处理时间段内正常执行内核。换句话说，SMM 既不是实模式也不是保护模式，因为我们知道内核的正常运行，相反，它执行一些保存在SMRAM中的特殊指令（存储在Bios Firmware中）。要检测它的延迟，您可以尝试触发SMI（它可以是软件生成的）并尝试捕获在SMM模式下花费的总时间。要做到这一点，你可以编写一个Linux内核模块，因为你需要一些特殊权限才能发出SMI（我认为）。

对于实时系统，我认为如果能避免像SMI这样的中断，那就太好了。

Answer 3

您可以检查System Management是否为turbostat中断（SMI）提供服务。例如：

# turbostat sleep 120
[check column SMI for value greater than 0]

当然，您还可以据此计算SMI频率。

了解SMI实际上以一定速率发生是重要的信息。但是您还想知道系统管理模式（SMM）在这些中断中花费了多少时间。例如，如果SMI中断仅非常短，而不是与实时应用程序无关。另一方面，如果您的硬件具有较长的SMI中断，则可能要与供应商联系，（如果可能）对固件进行不同的配置，或者切换到侵入性较小的SMM的其他硬件。

perf工具的模式可以测量SMI期间SMM中花费了多少个周期（使用信息provided by certain CPU counters）。示例：

# perf stat -a -A --smi-cost -- sleep 120
 Performance counter stats for 'system wide':

               SMI cycles%                 SMI# 
CPU0                      0.0%                    0 
CPU1                      0.0%                    0 
CPU2                      0.0%                    0
CPU3                      0.0%                    0

    120.002927948 seconds time elapsed

您还可以使用以下方法查看原始值：

# perf stat -a -A --smi-cost --metric-only -- sleep 120

据此，您可以计算出SMI平均在您的计算机上花费的时间。（将周期差异除以每个时间单位的周期数）。

将基于CPU计数器的结果与经验值进行交叉检查肯定是有意义的。

您可以使用Linux内核中集成的Linux Hardware Latency Detector。用法示例：

# echo hwlat > /sys/kernel/debug/tracing/current_tracer
# echo 1 > /sys/kernel/debug/tracing/tracing_thresh
# watch -d -n 5 cat /sys/kernel/debug/tracing/tracing_max_latency
# echo "Don't forget to disable it again"
# echo nop > /sys/kernel/debug/tracing/current_tracer

这些工具在CentOS / RHEL 7上可用，并且在其他发行版中也应该可用。

关于球场数据：最近，我遇到了一台HP 2011式的ProLiant Gen8 Xeon服务器，该服务器每分钟触发504个SMI。 Perf计算出的SMM率为0.1％，并且基于计数器值，SMI中花费的平均时间高达几微秒-但是Linux hwlat检测器无法检测到该系统上的如此高的中断。

该SMI比率与其Configuring and tuning HPE ProLiant Servers for low-latency applications指南（2017年10月）中的HP文档相符：

禁用对处理器的系统管理中断可提供以下功能之一低延迟环境的最大好处。禁用处理器电源和利用率监视SMI的影响最大之所以有效，是因为它在G6中每秒每秒八次产生处理器中断和更高版本的服务器。

（重点是我的；该指南还记录了其他SMI来源）

在装有Intel Atom C3758和Intel NUC（i5-4250U）系统的Supermicro板上，完全计数为零的SMI。

在基于Intel i7-6600U的戴尔笔记本电脑上，系统每分钟报告8个SMI，但aperf计数器低于不应发生的（未停止）周期计数器。

Answer 4

实际上，SMI不仅仅用于键盘模拟。服务器使用SMI报告和纠正ECC内存错误，ACPI使用SMI与BIOS通信并执行某些任务，甚至启用和禁用ACPI通过SMI完成，BIOS通常通过SMI拦截电源状态更改...还有更多，这只是几个例子。

Answer 5

根据System Management Mode上的wikipage，在正常操作期间不使用SMI，除非模拟带有USB物理键盘的PS / 2键盘。

大多数Linux系统都可以在没有仿真的情况下驱动正版USB键盘。您可以配置BIOS以禁用它。

评估Linux-CentOS / Intel机器上的SMI（系统管理中断）延迟

5 个答案: