英特尔 Turbo Boost 是否正在为我的 AWS EC2 云实例（它是 Xen 来宾）运行？
ec2-guest# ./showboost
中央处理器频率：2500
Turbo MHz : 2900 (10 活跃)
涡轮比 : 116% (10 active)
CPU 0 每 5 秒汇总一次…
TIME C0_MCYC C0_ACYC 使用率 MHz
06:11:35 6428553166 7457384521 51% 116% 2900
06:11:40 6349881107 7365764152 50% 115% 2899
06:11:45 6240610655 7239046277 49% 115% 2899
06:11:50 6225704733 7221962116 49% 116% 2900
[…]
是的！这些 2500 MHz CPU 当前以 2900 MHz 运行。
我猜CPU足够冷，可以提升。他们的温度是多少？
ec2-guest# ./cputemp 1
CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12 CPU13 CPU14 CPU15 CPU16
70 68 68 65 63 63 61 60 68 64 64 63 62 61 70 68
70 68 69 65 63 63 61 61 68 65 63 63 61 61 70 69
70 69 69 65 63 63 61 60 69 65 64 63 61 61 69 69
69 69 69 66 64 64 61 61 68 65 64 64 61 61 70 69
[…]
相对凉爽：在 60 到 70 摄氏度之间。这是我的另一个工具msr-cloud-tools。
在这篇文章中，我将描述 MSR、如何阅读它们以及为什么测量涡轮增压很重要。
特定型号寄存器 (MSR)
Aka机器特定寄存器，这些在Intel 64 和 IA-32 架构软件开发人员手册的第 3c 卷中进行了描述。他们访问低级 CPU 信息，包括涡轮增压比和温度读数。使用 RDMSR 和 WRMSR 指令读取和写入它们。
右图显示了使用 EC2 实例上的 MSR 测量的 CPU 温度如何根据 CPU 利用率（蓝色）而变化。工作负载是合成的：所有 CPU 驱动到 100% 利用率 5 分钟，然后到 0% 一段时间，重复。有趣的是，温度最初随着 CPU 负载而升高，然后急剧下降。系统爱好者有没有加入？ （到目前为止，我还没有找到风扇 RPM MSR 来确认。）
我通常关注性能监控计数器（PMC；也称为性能检测计数器 (PIC)、CPU 性能计数器 (CPC) 等）。这些由 RDPMC 阅读，并在同一手册的第 3b 卷中进行了描述。这些可以测量数据缓存未命中、停顿周期和其他有用的性能事件。
在 AWS EC2 上，在云实例（Xen 来宾）中，PMC 不可用，如您将看到的“perf stat”。这并不意味着它们永远无法工作，只是它们（或它们的控制 MSR）当前不可用。
但是 EC2 上提供了一小部分 MSR。以下是我发现的更有趣的：
Reg Name Description
0xe7 IA32_MPERF Bits 63:0 is TSC Frequency Clock Counter C0_MCNT TSC relative
0xe8 IA32_APERF Bits 63:0 is TSC Frequency Clock Counter C0_ACNT actual clocks
0x19c IA32_THERM_STATUS Bits 22:16 is the CPU therm status digital readout (DO)
0x1a2 MSR_TEMPERATURE_TARGET Bits 23:16 is temp target (TT)
0x1ad MSR_TURBO_RATIO_LIMIT Bits 7:0 is the turbo boost ratio (x100 for MHz) for 1 core active
0x1ae MSR_TURBO_RATIO_LIMIT1 Bits 15:8 (for example) is the turbo boost ratio for 10 cores active
Table 1. MSRs for Intel(R) Xeon(R) CPU E5-2670 v2
这些被各种内核例程使用，例如空闲线程和 cpufreq。
请注意，这些是特定于模型的，这意味着它们可以在不同的处理器模型（微架构）之间有所不同。 例如，Silvermont 在 MSR_TEMPERATURE_TARGET（位 29:24）中有一个读/写目标偏移量，它可以降低油门温度 (PROCHOT)。 这种差异使 MSR 不便携且难以使用，这就是为什么像 PAPI 这样的标准很重要的原因。
Reading MSRs
以下是测量 MSR 的方法（假设为 Intel）：
- 确定你的 CPU 类型和微架构
# head /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
型号：62
型号名称：Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
[...]
系列和型号告诉我们这是 Ivy Bridge 微架构（参见Intel 解码器）。您还可以使用 cpuid 工具（来自 cpuid 包），它应该直接报告微架构。
2. 查找您的处理器类型的 MSR
这些在英特尔软件开发人员手册的第 3c 卷中。这是一本 540 页的书，如果您是新手，在掌握它之前，您会迷路几次。
3.安装和加载msr-tools：
# apt-get install msr-tools
# modprobe msr
（假设是 Ubuntu。） msr-tools 包添加了 rdmsr 和 wrmsr 工具，以及 msr 内核模块。
4.使用rdmsr
基于（2）中的地址。 例如，要在 10 个内核处于活动状态时读取涡轮增压比（Ivy Bridge）：
# rdmsr 0x1ae -f 15:8 -d
29
乘以 100 得到 MHz。这些工作的方式在手册前面已经解释过了。
我确实在 msr-cloud-tools 集合中分享了一些工具，但是，我只为我当前正在分析的处理器类型编写了它们。您可能需要编辑它们以使用正确的 MSR。
为什么要测量涡轮增压
我们生活在一个令计算机性能分析师烦恼的时代：许多测量的误差幅度超过 10%，这要归功于 turbo Boost，这是一种可以动态超频 CPU 的英特尔处理器技术。 Ubuntu 比 CentOS 快 10%？可能只是涡轮增压。新软件版本退步 5%？可能只是涡轮增压。 Tunable 让事情快了 10%？可能只是…你明白了。
涡轮增压可以使 2500 MHz 处理器以 3300 Mhz 运行，具体取决于包括温度、功耗和内核 C 状态在内的因素。较冷的服务器运行得更快。我曾经在机架的顶部和底部有两台相同的服务器，顶部服务器的运行速度提高了 5%，因为它从空调接收到更多的冷空气。这既伟大又令人抓狂：我会采用更好的性能，但是当我比较系统或软件时，它也会弄乱测量结果。
我在历史上处理过这三种方法：
进行性能比较时，请在 BIOS 中关闭涡轮增压。
使用 CPU 性能计数器测量实际 CPU 周期以观察涡轮增压率。
运行一个简短的实验（基准）来测量当前的循环率，例如 noploop。
如果您运行自己的数据中心，则可以全部完成。但是作为 AWS EC2 上的 Xen 来宾，您不能更改 BIOS 并执行 (1)。您可以执行选项 (3)，但在非常繁忙的系统上，这可能既耗时又困难（不太可靠）。直到最近，我还认为你不能做（2），然后我找到了 MSR …
发现 MSR
当 Netflix 的一位同事 Scott 提到他喜欢使用 i7z 命令来调试 turbo boost 时，我正在研究一个可疑的 turbo boost 问题。我们认为它不适用于 EC2，但我还是尝试了。
大多数输出显然是错误的，但只有一列温度读数表明某些东西正在工作。使用我的 ftrace perf-tools集合中的 opensnoop 来查看如何：
# ./opensnoop -n i7z
跟踪进程名称“i7z”发出的 open()。Ctrl-C 结束。
通讯 PID FD 文件
i7z 8427 0x3 /proc/cpuinfo
i7z 8427 0x3 /dev/cpu/0/msr
i7z 8427 0x3 /dev/cpu/0/msr
i7z 8427 0x3 /dev/cpu/0/msr
i7z 8427 0x3 /dev/cpu/0/msr
[...]
这表明 i7z 正在读取 /dev/cpu/0/msr，并引导我仔细查看可用的 MSR。
我通常会使用 CPU_CLK_Unhalted.Core，但这不可用。经过一番挖掘，我发现我可以使用 IA32_APERF deltas 与 IA32_MPERF deltas 的比率，它显示了当处理器处于 C0 状态时时间戳计数器（TSC，它是基于周期的）移动的速度有多快。
找到一种直接测量实际时钟速率和涡轮增压的方法是一个巨大的解脱。我的误差范围消失了：我可以再次测量性能。
安全轶事
（更新）当我发现我可以访问 EC2 中的 MSR 时，我运行了各种 Internet 搜索（“EC2 MSR”、“AWS MSR”、“Xen MSR”、“Cloud MSR”等），但一无所获。这不是任何人发布的主题。我认为在这里分享它会很有用，并成为第一个向全世界介绍云中 MSR 的人。Netflix 工程的一个好故事：以低级调试引领潮流。
但这也可能适得其反。我以前发现过内核恐慌之类的奇怪事情并发布了它们，然后我会看到安全研究人员根据我分享的内容跟进漏洞。这些都是好人！（坏人发现但不分享。）MSR 是一种不寻常的资源，可用于修改硬件设置。可能存在 EC2 漏洞吗？
现在我会要求我们的安全团队和 AWS 进行调查。但在 2014 年，我是一名新员工，我想我会亲自检查一下，尤其是因为我之前曾在安全部门工作过。我开发了一个模糊器来逐步检查所有可能的 MSR，编写不同的值来检查结果。同时，我检查了系统的各种属性，包括 dmesg 是否有任何诱发的故障。没有什么不好的事情发生，许多 MSR 的写信都被拒绝了。AWS 似乎已经考虑了安全隐患并构建了 MSR 防火墙。
我与包括我的经理在内的其他人聊过关于上市的问题，有人担心如果 AWS 认为它们在 VM 之间过度共享信息，他们可能会禁用它们。我认为这不太可能，因为他们提供的信息几乎没有提供这样的洞察力。它是温度、用电量和其他广泛的指标。
所以我在 2014 年 9 月 15 日公开了这篇文章，并将 MSR 包括在我 9 月 25 日在巴尔的摩举行的 Surge 演讲中：从云到根（幻灯片 84 到 87）。9 月 26 日，我回到工作岗位，发现 CORE SRE 团队忙于活动：AWS 宣布全球云重启！虽然 Netflix 定期测试从丢失可用区的恢复，但这将测试失去一切——整个云——以及我们从没有在线服务中恢复的能力。CORE 团队正在探索启动过程，如果某些服务在其他服务之前启动会发生什么，以及如果它们失败了如何解决问题。
同时，我有一种下沉的感觉。我给我们的技术客户经理 (TAM) 发了消息，感到有些内疚：“这是我造成的吗？这与 MSR 有关吗？” 他回答说他不这么认为，因为他听说是 Xen，但他不知道全部细节，因为它们处于禁运状态。
禁运于 10 月 1 日到期，我终于看到了漏洞摘要：
“Xen 安全公告 108 (CVE-2014-7188) - 用于 x2APIC 仿真的 MSR 范围不正确”
这是MSR！在这篇文章之前，我知道没有人在 EC2 上查看这些内容。我再次联系了我们的 TAM，“这真的是我，不是吗？” 这一次他没有确认也没有否认，但确实回复了：“下次你在我们的处理器上发现有趣的东西，请先告诉我们！ ”
这就是我可能对 2014 年全球云重启负有部分责任的故事。感谢 Jan Beulich 发现漏洞 ( XSA-108 )，感谢 AWS 在细节公开之前修复和部署漏洞。AWS 之后也禁用了温度 MSR，从那以后我就一直在戏弄我们的 TAM：“我们什么时候才能恢复温度？” （那时我没有问他关于 PEBS 的事。）
结论
Xen 来宾（包括 AWS EC2）中提供了一些特定于模型的寄存器 MSR。这些允许测量实际时钟速率和涡轮增压程度。这对于任何性能比较都很重要，因为涡轮增压的变化可能会使结果偏差超过 10%，具体取决于测试期间服务器的冷热程度。
到目前为止，我已经在msr-cloud-tools中编写了几个工具来测量 CPU 涡轮增压和温度。与 MSR 的性质一样，它们特定于处理器类型，并且这些脚本（到目前为止）仅适用于我们的 Intel(R) Xeon(R) CPU E5-2670 v2s。如果您想自己使用这些工具或 MSR，您可能需要找到适合您的处理器类型的 MSR。好消息是英特尔和 AMD 的供应商文档非常好，尽管需要一些时间来挖掘。
转载翻译自: https://www.brendangregg.com