x86 tsc相关知识

像gettimeofday() and clock_gettime这种系统调用，它可能会比一般其他的其他系统调用更快，因为它本身是获取时间的，如果它本身耗时的话，那就不精确了，他们的精度是ns级别的。

tsc指令并不要求在特权级别下执行，所以完全可以在用户态执行rdtsc指令。

Variant TSC
The first generation of TSC, the TSC increments could be impacted by CPU frequency changes. This is started from a very old processors (P4).

Constant TSC
The TSC increments at a constant rate, even CPU frequency get changed. But the TSC could be stopped when CPU run into deep C-state. Constant TSC is supported before Nehalem, and not as good as invariant TSC.

Invariant TSC
The invariant TSC will run at a constant rate in all ACPI P-, C-, and T-states. This is the architectural behavior moving forward. Invariant TSC only appears on Nehalem-and-later Intel processors.

constant tsc与invariant tsc是不一样的概念。nonstop tsc又是什么？ 

应该是这样的，linux中constant tsc + nonstop tsc = invariant tsc。 nonstop tsc是tsc在deep c state下还能保持恒定的频率。

https://github.com/torvalds/linux/commit/40fb17152c50a69dc304dd632131c2f41281ce44

但坑爹的是即使有这几个标识你以为tsc就可靠了吗？no

早期的smp系统中，tsc可能不同步（vmware比较吊，用软件的方法保证了tsc的可靠性，所以直接在cpu flag中搞了一个tsc_reliable标志位）。

在芯片支持invariant tsc后服务器厂商一般在服务器启动的时候，在所有的cpu收到reset信号的时候开始以同样的频率计时。这样就比较可靠了。 Linux内核为了确保tsc可靠，在系统启动的时候会去测试tsc的可靠性。

 

CPU热插拔：

CPU热插拔的时候要同步tsc，以前在内核代码中去尝试用软件方法同步，不过有问题，所以近期代码都删掉了。所以同步主要是硬件/固件行为，内核应该只是负责测试，如果不同步，那么tsc会被标记为不可靠的时钟源。

 

RDTSC陷阱：

一定要注意使用mb，因为rdtsc可能会出现指令乱序执行（LFENCE;RDTSC.）。

 

各虚拟化厂商对RDTSC的实现：

vmware5.x开始使用混合方案：如果硬件支持tsc之间同步的话，那么它的性能很好；如果硬件不支持tsc同步，那么软件可以保证tsc在vcpu之间的同步。

hyper-v：不支持rdtsc的模拟。但是如果你把tsc特性透传过去的话，那么tsc还是可以用的，只是没办法保证他的可靠性。所以如果linux内核感知到自己运行在hyper-v平台上，那么久把tsc时钟源设置为不可靠的。

https://blog.csdn.net/yayong/article/details/50639800

 

tsc同步应该是硬件去做的，如果软件可以做的话，那就不存在tsc不可靠而回退到hpet时钟源的事情。也可以看出，内核是可以回退的，但是如果用户态去rdtsc就无药可救了。

tsc补偿在linux下是怎么实现的呢？ 感觉tsc在kvm中也是可靠的，因为它有offset和scaling，同步的问题应该也可以在内核中测量出来的。