linux - 用于基准测试和时间戳计数器频率的 rdtsc 的准确性

Question

作为基准测试任务的一部分，我正在研究可用于测量耗时的不同机制。我最终决定使用 clock_gettime，但我也对 RDTSC 指令进行了充分的研究和测试。我有几个关于相同的问题(基于我在几个在线线程上阅读的内容):

• 在较新的处理器(>Pentium 4)上，TSC 以系统 CPU 的最大频率运行。这个对吗？在那种情况下，使用滴答数和频率来确定时间是否有效？

• 如果上述为真，则表示 TSC 不受因省电和其他功能而导致的 CPU 频率变化的影响。知道这一点，是否意味着通过使用 RDTSC 获得的总滴答声不是采样代码段使用的实际滴答声 - 因为代码将以 CPU 的频率而不是 TSC 的频率运行？另外，这是否意味着使用 TSC 节拍和 CPU 频率获得的时间不是代码段实际使用的时间？

• 我发现了很多关于跨核心同步 TSC 值的不同说法(参见 this thread )。我不确定什么是正确的，我猜这也取决于处理器型号。但是可以假设它在较新的 CPU 上的内核之间是同步的吗？ (这没有使用 sched_set_affinity)？

请注意，由于与之相关的各种问题(便携性、可靠性等)，我没有使用 RDTSC。这些问题只是为了提高我对 TSC 工作原理和一般基准测试的理解。

Answer 1

根据 Intel 的说法，不变的 TSC 意味着

The invariant TSC will run at a constant rate in all ACPI P-, C-. and T-states.

但那是什么比率？嗯，

That rate may be set by the maximum core-clock to bus-clock ratio of the processor or may be set by the maximum resolved frequency at which the processor is booted. The maximum resolved frequency may differ from the maximum qualified frequency of the processor, see Section 18.14.5 for more detail. On certain processors, the TSC frequency may not be the same as the frequency in the brand string.

在我看来，他们似乎希望它成为品牌字符串中的频率，但不知何故并不总是正确的..那频率是多少？

The TSC, IA32_MPERF, and IA32_FIXED_CTR2 operate at the same, maximum-resolved frequency of the platform, which is equal to the product of scalable bus frequency and maximum resolved bus ratio.
For processors based on Intel Core microarchitecture, the scalable bus frequency is encoded in the bit field MSR_FSB_FREQ[2:0] at (0CDH), see Appendix B, "Model-Specific Registers (MSRs)". The maximum resolved bus ratio can be read from the following bit field:
If XE operation is disabled, the maximum resolved bus ratio can be read in MSR_PLATFORM_ID[12:8]. It corresponds to the maximum qualified frequency.
If XE operation is enabled, the maximum resolved bus ratio is given in MSR_PERF_STAT[44:40], it corresponds to the maximum XE operation frequency configured by BIOS.

虽然这可能不是很有帮助。 TL;DR，以编程方式找到 TSC 率太费力了。您当然可以在自己的系统上轻松找到它，只需根据定时循环进行不准确的猜测并取“最接近的有意义的数字”即可。无论如何，它可能是品牌字符串中的数字。它在我测试过的所有系统上都有，但我没有测试过那么多。如果不是，那将是一个明显不同的比率，所以您肯定会知道。

In addition, does this mean the time obtained by using the TSC ticks and CPU frequency isn't the actual time used by the code piece?

是的，但并不是所有的希望都破灭了，通过使用 TSC 刻度和 TSC 速率(如果您不知何故知道的话)获得的时间将给出实际时间..几乎？这里通常会冒出很多关于不可靠性的 FUD。是的，RDTSC 没有序列化(但您可以添加序列化指令)。 RDTSCP 正在序列化，但在某些方面还不够(它不能执行得太早，但可以执行得太晚)。但这并不是说你不能使用它们，你可以接受一个小错误，或者阅读我在下面链接的论文。

But can it be assumed to be synchronized among cores on newer CPUs?

是的，不，也许——它将被同步，除非写入 TSC。谁知道，有人可能会这样做。不受你的控制。它也不会在不同的套接字之间同步。

最后，我真的不相信在基准测试的背景下对 RDTSC(P) 的恐惧。您可以根据需要对其进行序列化，TSC 是不变的，并且您知道速率，因为它是您的系统。实际上也没有任何替代方案，它基本上是 高分辨率时间测量的来源，最终其他所有东西最终都会使用。即使没有特别的预防措施(但通过过滤数据)，大多数基准测试的准确性和精确度都很好，如果您需要更多，请阅读 How to Benchmark Code Execution Times on Intel® IA-32 and IA-64 Instruction Set Architectures ，他们编写了一个内核模块，这样他们就可以摆脱另外两个基准错误源，这两个源头容易受到很多 FUD、抢占和中断的影响。