相关疑难解决方法(0)

假设我们正在尝试使用tsc进行性能监控,我们希望防止指令重新排序.

这些是我们的选择:

1: rdtscp是序列化调用.它可以防止对rdtscp的调用进行重新排序.

__asm__ __volatile__("rdtscp; "         // serializing read of tsc
                     "shl $32,%%rdx; "  // shift higher 32 bits stored in rdx up
                     "or %%rdx,%%rax"   // and or onto rax
                     : "=a"(tsc)        // output to tsc variable
                     :
                     : "%rcx", "%rdx"); // rcx and rdx are clobbered

但是,rdtscp仅适用于较新的CPU.所以在这种情况下我们必须使用rdtsc.但是rdtsc非序列化,因此单独使用它不会阻止CPU重新排序.

所以我们可以使用这两个选项中的任何一个来防止重新排序:

2:这是一个电话cpuid然后rdtsc.cpuid是一个序列化的电话.

volatile int dont_remove __attribute__((unused)); // volatile to stop optimizing
unsigned tmp;
__cpuid(0, tmp, tmp, tmp, …

我有一个在Atom上运行的嵌入式Linux系统，这是一个足够新的CPU，具有不变的TSC（时间戳记计数器），内核在启动时测量其频率。我在自己的代码中使用TSC来节省时间（避免内核调用），而我的启动代码会测量TSC速率，但我只想使用内核的度量值。有什么办法可以从内核中检索到它吗？它不在/ proc / cpuinfo中。

我正在尝试在 x86-64 处理器上分析执行时间的代码。我指的是这篇英特尔白皮书，并且还浏览了其他 SO 线程，讨论了在此处和此处使用 RDTSCP 与 CPUID+RDTSC 的主题。

在上面提到的白皮书中，使用 CPUID+RDTSC 的方法被称为不可靠，并且也使用统计数据进行了证明。

CPUID+RDTSC 不可靠的原因可能是什么？

此外，同一白皮书中的图 1（最小值行为图）和图 2（方差行为图）中的图具有“方波”模式。什么解释了这种模式？