我想知道当上下文切换发生时，是否有人知道有关 Linux 中时间戳计数器的更多详细信息？到目前为止，我的观点是，TSC 值在每个时钟周期内仅增加 1，无论是在内核模式下还是在用户模式下都是独立的。我现在使用 TSC 测量了一个应用程序的性能，它产生了 5 个 Mio 时钟周期的性能结果。然后，我对调度程序进行了一些更改，这意味着上下文切换需要更长的时间，例如 2 个 Mio 周期而不是 500.000 个周期。有趣的是，当再次测量原始应用程序的性能时，它仍然需要 5 个 Mio 周期......所以我想知道为什么它没有花费更长的时间，因为上下文切换现在需要将近 2 个 Mio 时钟周期？（并且在应用程序执行期间至少出现 3 个上下文）。
时间戳计数器是否在内核模式期间以某种方式停用？还是在比赛切换时保存了 TSC 的内容？谢谢，如果有人能指出我可能是什么问题！
正如你可以在维基百科上阅读的
随着多核/超线程 CPU、具有多个 CPU 的系统和“休眠”操作系统的出现，不能依靠 TSC 来提供准确的结果。该问题有两个组成部分：滴答速率以及所有内核（处理器）是否在其计时寄存器中具有相同的值。无法保证单个主板上多个 CPU 的时间戳计数器会同步。在这种情况下，程序员只能通过将代码锁定到单个 CPU 来获得可靠的结果。即使这样，由于操作系统或 BIOS 采取的节能措施，CPU 速度可能会发生变化，或者系统可能会休眠并稍后恢复（重置时间戳计数器）。对时间戳计数器的依赖也降低了可移植性，因为其他处理器可能没有类似的功能。最近的英特尔处理器包括一个恒定速率 TSC（由 Linux 的 /proc/cpuinfo 中的 constant_tsc 标志标识）。使用这些处理器，TSC 以处理器的最大速率读取，而不管 CPU 的实际运行速率如何。虽然这使时间保持更加一致，但它可能会扭曲基准，其中在操作系统将处理器切换到更高速率之前，一定量的启动时间会以较低的时钟速率花费。这会使事情看起来比通常需要更多的处理器周期。在操作系统将处理器切换到更高速率之前，一定量的启动时间会以较低的时钟速率花费。这会使事情看起来比通常需要更多的处理器周期。在操作系统将处理器切换到更高速率之前，一定量的启动时间会以较低的时钟速率花费。这会使事情看起来比通常需要更多的处理器周期。
我相信 TSC 实际上是您正在使用的处理器的硬件结构。IE：读取 TSC 实际上使用 RDTSC 处理器操作码。我什至认为操作系统没有办法改变它的值，它只会随着上次电源重置后的每个滴答声而增加。
关于您对调度程序的修改，您是否有可能使用多核处理器，而操作系统不会切换您正在运行的进程？您可以调用sched_yield()或sleep(0)在您的程序中查看您的调度程序更改是否开始生效。