评估Linux-CentOS/Intel机器上的SMI(系统管理接口)延迟

uyhoqukh  于 2023-11-17  发布在  Linux
关注(0)|答案(5)|浏览(136)

我感兴趣的是评估运行CentOS的Linux机器上SMI处理的行为(延迟,频率),并用于(非常)软的真实的时间应用程序。
1.推荐哪些工具(CentOS的hwlatdetect?),最好的行动方案是什么?
1.如果CentOS没有好的工具,那么我是否可以假设在同一台机器上安装不同的操作系统会产生相同的结果,因为底层硬件/BIOS是相同的?
1.有没有关于这些参数的大致数字的来源。
这些机器是X86_64架构,运行CentOS 6.4(内核2.6.32-358.23.2.el2.centos.plus.x86_64)。

9ceoxa92

9ceoxa921#

在正常运行期间,SMI肯定会发生。我的家用台式机在芯片组中启用了芯片组驱动的SMI,每秒钟半一次。我也见过一些服务器,由于BIOS驱动的CPU频率缩放方案,它们每秒两次。然而,有些系统可以长时间不发生SMI,所以这真的取决于。
问题1:hwlatdetect是检测系统上发生SMI的延迟的一个选项。BIOSBITS是另一个选项,它是一个可引导的CD,可以识别是否发生SMI。您还可以通过创建一个在循环中旋转并获取时间戳的内核模块来编写自己的测试(使用RDTSC)。如果您看到两个时间戳读数之间有很长的间隔,你可以查询CPU MSR 0x34,看看SMI计数器是否增加,这表明发生了SMI。
如果你想生成一个SMI,你可以创建一个内核模块,它对端口0xb2执行OUT CPU指令,例如,向这个端口写入一个值0。(你也可以通过收集写入端口0xB2之前和之后的时间戳来计算这个SMI的时间)。
问题#2,SMI在操作系统之下的一层运行,因此您选择的操作系统不应该有任何影响。
问题3:BIOSBITS建议SMI延迟保持在150微秒以下。

3b6akqbq

3b6akqbq2#

SMI会将您的系统放入SMM(System Management Mode)模式,它会在SMI处理时间段内推迟内核的正常执行,换句话说,SMM既不是我们所知道的内核正常运行的真实的模式,也不是保护模式,相反,它执行一些保存在SMRAM中的特殊指令(存储在Bios固件中)。要检测它的延迟,您可以尝试触发SMI(它可以是软件生成的),并尝试捕获SMM模式所花费的总时间。要实现这一点,您可以编写一个Linux内核模块,因为你需要一些特权来发布SMI(我想)。
对于真实的时间系统,我认为如果你能避免像SMI这样的中断,那就太好了。

vcudknz3

vcudknz33#

您可以使用turbostat检查System Management中断(SMI)是否得到服务。例如:

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

字符串
当然,你也可以从中计算出SMI频率。
知道SMI实际上以一定的速率发生是很重要的信息。但是你也想知道系统管理模式(SMM)在这些中断中花费了多少时间。例如,如果SMI中断非常短,那么它可能与你的实时应用无关。另一方面,如果你有长SMI中断的硬件,你可能想和供应商谈谈,以不同方式配置固件(如果可能)和/或切换到具有较少侵入性SMM的其他硬件。
perf工具有一种模式,可以测量SMI期间在SMM中花费了多少周期(使用某些CPU计数器提供的信息)。示例:

# 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 --no-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 Gen 8 Xeon服务器,它每分钟触发504个SMI。Perf在SMM中计算出的速率为0.1%,根据计数器值,SMI中花费的平均时间高达几微秒-但Linux hwlat检测器在该系统上检测不到如此高的中断。
该SMI比率与HP在其Configuring and tuning HPE ProLiant Servers for low-latency applications指南(2017年10月)中的文件相匹配:
对处理器禁用系统管理中断为低延迟环境提供了最大的好处之一。禁用处理器电源和利用率监视SMI具有最大的效果,因为它在G6和更高版本的服务器中每秒生成处理器中断八次
(强调我的;该指南还记录了其他SMI来源)
在一个Supermicro板与英特尔凌动C3758和英特尔NUC(i5- 4250 U)系统的地雷有确切的零SMI计数。
在基于Intel i7- 6600 U的戴尔笔记本电脑上,系统报告每分钟8个SMI,但aperf计数器低于(未停止)周期计数器,这是不应该发生的。

2wnc66cl

2wnc66cl4#

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

j8yoct9x

j8yoct9x5#

根据System Management Mode上的wikipage,SMI在正常操作期间不使用,除非用USB物理键盘模拟PS/2键盘。
大多数Linux系统都可以在没有模拟的情况下驱动真正的USB键盘,你可以配置你的BIOS来禁用它。

相关问题