您可以使用turbostat 检查是否处理了System Management 中断（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-ish 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 月）中记录的内容相符：
禁用处理器的系统管理中断提供了一种
对低延迟环境的最大好处。
禁用处理器电源和利用率监控 SMI 具有最大的
因为它在 G6 中生成处理器中断每秒八次
和更高版本的服务器。
（强调我的；该指南还记录了其他 SMI 来源）
在配备英特尔凌动 C3758 和我的英特尔 NUC (i5-4250U) 系统的 Supermicro 主板上，计算的 SMI 恰好为零。
在基于 Intel i7-6600U 的戴尔笔记本电脑上，系统每分钟报告 8 个 SMI，但 aperf 计数器低于（未暂停）周期计数器，这是不应该发生的。