在Linux-CentOS/Intel机器上评估SMI(系统管理中断)延迟 [英] Evaluating SMI (System Management Interrupt) latency on Linux-CentOS/Intel machine

查看:407
本文介绍了在Linux-CentOS/Intel机器上评估SMI(系统管理中断)延迟的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I am interested in evaluating the behavior (latency, frequency) of SMI handling on Linux machine running CentOS and used for a (very) soft real time application.

  1. 推荐使用哪些工具(适用于CentOS的hwlatdetect?),什么是最好的解决方案?

  1. What tools are recommended (hwlatdetect for CentOS?), and what is the best course of action to go about this?

如果没有适用于CentOS的好的工具,我是否正确假设安装了CentOS. 同一台计算机上的不同操作系统应该产生相同的结果,因为底层的硬件/BIOS是相同的?

If no good tools are available for CentOS, am I correct to assume that installing a different OS on the same machine should yield the same results since the underlying hardware/bios are the same?

在这些参数上是否有关于球场数字的资料.

Is there any source for ballpark figures on these parameters.

这些计算机是X86_64架构,运行CentOS 6.4(内核2.6.32-358.23.2.el2.centos.plus.x86_64.)

The machines are X86_64 architecture, running CentOS 6.4 (kernel 2.6.32-358.23.2.el2.centos.plus.x86_64.)

推荐答案

SMI在正常运行期间肯定会发生.我的家用台式机每隔一半有一个由芯片组驱动的SMI,该SMI在芯片组中启用.我还看到有些服务器由于BIOS驱动的CPU频率缩放方案而每秒两次拥有它们.但是,某些系统可能会长时间运行而不会发生SMI,因此这取决于实际情况.

SMIs can certainly happen during normal operation. My home desktop has a chipset-driven SMI every second and a half which is enabled in the chipset. I've also seen some servers that have them twice a second due to a BIOS-driven CPU frequency scaling scheme. However, some systems can go long periods of time without an SMI occurring so it really depends.

问题1:hwlatdetect是检测系统上发生的SMI延迟的一种方法. BIOSBITS是另一种选项,它是可引导CD,可以识别是否正在发生SMI.您还可以通过创建一个内核模块来编写自己的测试,该内核模块循环旋转并占用时间戳(使用RDTSC).如果您看到两个时间戳读数之间有很长的间隔,则可以查询CPU MSR 0x34,以查看SMI计数器是否增加,这表明发生了SMI.

Question #1: hwlatdetect is one option to detect the latency of SMIs occurring on your system. BIOSBITS is another option which is a bootable CD that can identify if SMIs are occuring. You can also write your own test by creating a kernel module that spins in a loop and takes timestamps (using RDTSC). If you see a long gap between two timestamp readings, you could consult CPU MSR 0x34 to see if the SMI counter incremented which would indicate that an SMI happened.

如果要生成SMI,则可以制作一个对端口0xb2执行OUT CPU指令的内核模块,例如向该端口写入值0. (您也可以通过在写入端口0xB2之前和之后收集一个时间戳来计时此SMI).

If you want to generate an SMI, you can make a kernel module that does an OUT CPU instruction to port 0xb2, e.g. write a value of 0 to this port. (You can also time this SMI by gathering a timestamp just before and just after the write to port 0xB2).

问题2,SMI在操作系统下一层运行,因此您选择的操作系统不会产生任何影响.

Question #2, SMIs operate at a layer below the OS so which OS you choose, shouldn't have any impact.

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

Question #3: BIOSBITS recommends that SMI latencies be kept under 150 microseconds.

这篇关于在Linux-CentOS/Intel机器上评估SMI(系统管理中断)延迟的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆