TSC频率通用解决方案：提升性能分析与基准测试的准确性

你是否曾尝试使用LLVM的X-Ray性能分析工具生成火焰图，却遇到如下晦涩错误：

1
2


==65892==Unable to determine CPU frequency for TSC accounting.
==65892==Unable to determine CPU frequency.

或者更糟的是，当你分析应用程序中每个函数的运行时，发现所有函数运行时间总和只占20分钟运行时间的约15分钟？那丢失的5分钟去哪了？

我们遇到了这两种情况，因此构建了一个名为tsc_freq_khz的Linux内核模块解决方案。我们将快速但深入地探讨x86计时器来解释这个问题，但首先让我们看看这个方案的好处。

模块优势

tsc_freq_khz模块在虚拟化环境中增强了X-Ray等性能分析和基准测试工具的性能。不再出现"无法确定CPU频率"错误！

该模块还使这些工具在新款Intel处理器上更加准确。X-Ray使用x86时间戳计数器（TSC）——一种低延迟单调递增时钟——来测量事件持续时间，并假设TSC频率等同于最大时钟速度。这个假设在新款CPU上是错误的，会导致时间测量不准确。tsc_freq_khz模块提供了读取实际TSC频率的方法。性能分析数据中不再丢失分钟！

工作原理

tsc_freq_khz模块通过sysfs将Linux内核内部的x86时间戳计数器（TSC）频率值tsc_khz导出到用户空间。程序可以通过读取/sys/devices/system/cpu/cpu0/tsc_freq_khz来查询这个值。

像X-Ray和Abseil这样的几个开源项目已经检查tsc_freq_khz的存在，但直到现在，这个文件只存在于Google的生产内核中。tsc_freq_khz模块为其他所有人启用了TSC频率导出到用户空间的功能。

时间戳的问题

在我们解释我们所做的工作以及为什么这有效之前，让我们快速介绍x86架构上的时间戳。

x86机器至少有六种不同的时间测量方法：

实时时钟（RTC）
可编程间隔定时器（PIT）
高性能事件定时器（HPET）
ACPI电源管理定时器（ACPI PM）
高级可编程中断控制器（APIC）定时器
当然还有时间戳计数器（TSC）

每种方法都有独特而微妙的缺陷，使其在某些应用中完全不可行。这种计时器的丰富多样性是在保持30年向后兼容性且从不删除功能的情况下发生的，因为某个地方的某些人依赖它。

尽管存在许多缺陷，TSC对于基准测试和分析仍然有用。它具有极低的延迟，因为电路直接位于CPU上，并且可以直接从用户模式应用程序访问。像X-Ray这样非常有用的性能分析工具依赖TSC进行准确测量。

然而，TSC以滴答数测量时间，这些滴答数在不同处理器之间不可比较，因此在很大程度上没有意义。对于性能分析和基准测试，我们希望以可比较的单位（如纳秒）测量时间。

从滴答到纳秒

那么一个滴答中有多少纳秒？将某些持续时间的滴答转换为纳秒的基本公式很简单：

1

time_in_nanoseconds = (tsc_count_end - tsc_count_start) * tsc_frequency

不幸的是，确定TSC频率很困难，在某些情况下（例如基于云或其他虚拟化环境）甚至不可能。直到现在。

核心问题是Linux内核没有提供应用程序了解TSC频率的方法，尽管Linux perf实用程序确实尝试通过Intel PT计算TSC频率。有不直接暴露该值的合理理由，因为TSC频率相当晦涩，并且在某些情况下该值完全没有意义。直到最近，处理器的最大时钟速度也是TSC频率的准确近似值。

然而，这不再成立。使用最大时钟速度作为TSC频率将在新款Intel CPU上给出错误的结果。这是性能分析时丢失分钟的原因。

此外，在基于云或其他虚拟化环境中，无法通过/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq访问最大时钟速度。这是"无法确定CPU频率"错误的原因。

cpuinfo_max_freq由用于频率缩放（即根据省电设置使CPU运行更快或更慢）的cpufreq驱动程序填充。自然，频率缩放在虚拟化环境中通常不允许，因为每个物理CPU与多个虚拟租户共享。因此，这个值不存在。

Google的提示

X-Ray中的时间戳测量代码引用了一个神秘的sysfs条目/sys/devices/system/cpu/cpu0/tsc_freq_khz，听起来它正好提供了我们需要的东西：以千赫兹为单位的TSC频率。不幸的是，在Linux内核源代码中绝对没有对该文件的引用。这是怎么回事？

更多搜索在Abseil源代码中揭示了以下提示：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// Google's production kernel has a patch to export the TSC
// frequency through sysfs. If the kernel is exporting the TSC

// cannot be relied on because the BIOS may be exporting an invalid
// p-state (on x86) or p-states may be used to put the processor in
// a new mode (turbo mode). Essentially, those frequencies cannot
// always be relied upon. The same reasons apply to /proc/cpuinfo as
// well.
if (ReadLongFromFile("/sys/devices/system/cpu/cpu0/tsc_freq_khz", &freq)) {
  return freq * 1e3;  // Value is kHz.
}

中奖了！注释告诉我们：

Google在生产中运行自定义Linux内核
Google知道cpuinfo_max_freq不应用于基准测试
内核的TSC频率计算是合理的
Google的内部内核有一个通过sysfs导出TSC频率的补丁，但该补丁尚未上游到主内核树

TSC频率通用化！

为什么只有Google内核可以访问TSC频率？由于Linux内核是开源的，我们可以编写自己的内核模块来做同样的事情。幸运的是，Linux内核已经在启动期间计算TSC频率并将其存储在tsc_khz变量中。我们所要做的就是通过sysfs导出该变量。

我们的内核模块tsc_freq_khz正是这样做的。它创建了一个sysfs条目，读取内核定义的tsc_khz变量，并通过/sys/devices/system/cpu/cpu0/tsc_freq_khz导出它。该模块极其简单但也非常有用。

按照Github上的构建说明，通过将模块插入内核来测试它：

1
2
3
4
5


$ sudo insmod ./tsc_freq_khz.ko
$ dmesg | grep tsc_freq_khz
[14045.345025] tsc_freq_khz: starting driver
[14045.345026] tsc_freq_khz: registering with sysfs
[14045.345028] tsc_freq_khz: successfully registered

/sys/devices/system/cpu/cpu0/tsc_freq_khz处的文件现在应该被填充。（您系统上的值会不同。）

1
2


$ cat /sys/devices/system/cpu/cpu0/tsc_freq_khz
2712020

**警告：**请不要在真实生产系统中使用此代码。虽然它不应该引起问题，但它确实做了一些假设，例如CPU0存在。也没有健全性检查来警告TSC值是否不合理或不可靠。

结论

像这样看似简单的问题可能会让我们陷入一个迷人的兔子洞。随着时间的推移，Google的内部补丁可能会进入Linux内核，或者内核开发人员可能会创建自己的官方补丁来将TSC频率导出到用户空间。同时，对于那些希望使用LLVM优秀的X-Ray性能分析工具进行准确测量的人来说，tsc_freq_khz可以作为一个临时解决方案。