linux - 在内核模式和用户模式之间切换时的时间戳计数器 (TSC)

Question

我想知道是否有人知道有关发生上下文切换时 Linux 中的时间戳计数器的更多详细信息？直到现在我的观点是，TSC 值在每个时钟周期内只增加 1，无论是在内核模式还是在用户模式下都是独立的。我现在使用 TSC 测量了一个应用程序的性能，它产生了 5 个 Mio Clock Cyles 的性能结果。然后，我对调度程序进行了一些更改，这意味着上下文切换需要相当长的时间，即2 Mio 周期而不是 500.000 周期。有趣的是，当再次测量原始应用程序的性能时，它仍然需要 5 个 Mio 周期......所以我想知道为什么它没有花费相当长的时间，因为上下文切换现在需要将近 2 个 Mio 时钟周期？ (并且在应用程序执行期间至少出现 3 个上下文)。

时间戳计数器是否在内核模式期间以某种方式停用？还是在比赛切换期间保存了 TSC 的内容？谢谢，如果有人能指出我可能是什么问题!

Answer 1

正如您在 Wikipedia 上看到的那样

With the advent of multi-core/hyperthreaded CPUs, systems with multiple CPUs, and "hibernating" operating systems, the TSC cannot be relied on to provide accurate results. The issue has two components: rate of tick and whether all cores (processors) have identical values in their time-keeping registers. There is no promise that the timestamp counters of multiple CPUs on a single motherboard will be synchronized. In such cases, programmers can only get reliable results by locking their code to a single CPU. Even then, the CPU speed may change due to power-saving measures taken by the OS or BIOS, or the system may be hibernated and later resumed (resetting the time stamp counter). Reliance on the time stamp counter also reduces portability, as other processors may not have a similar feature. Recent Intel processors include a constant rate TSC (identified by the constant_tsc flag in Linux's /proc/cpuinfo). With these processors the TSC reads at the processor's maximum rate regardless of the actual CPU running rate. While this makes time keeping more consistent, it can skew benchmarks, where a certain amount of spin-up time is spent at a lower clock rate before the OS switches the processor to the higher rate. This has the effect of making things seem like they require more processor cycles than they normally would.