我正试图在Ubuntu 10.10机器上以编程方式从多个来源收集有关程序性能的数据。对于我的所有其他来源，我已经能够使用RDTSCx86指令收集它们，然后使用gettimeofday将它们缩放为绝对时间的秒。然而，当我开始尝试将这些数据源与在/sys/kernel/debug/tracing中执行sched_switch跟踪的输出进行协调时，我遇到了一个问题，因为我看到的输出是在未知时间后以秒和微秒为单位的。
我已经完成的步骤：
1.我已经确定Linux内核内部也使用RDTSC，但添加了一些它收集的偏移量，但我似乎没有能力检索。它也在每个核心的基础上这样做，这意味着我必须尝试所有四个核心，并确定最好的一个，这似乎是解决这个问题的糟糕方法
2.我试着在打开日志时转换RDTSC时间，看看至少转换本身是否一致（即一些恒定的偏移量），但在整个运行过程中，规模似乎并没有保持恒定
3.clock_gettime（clock_MONOTONIC，…）似乎有一个非常相似的值，但总是偏离一个不可接受的量（大约半秒），而且似乎也不完全一致。
如果我能够将其他数据源收集时间的方式更改为所需的方式（假设不是性能密集型），那么我应该如何收集时间，以便在跟踪的时间和我收集的时间之间进行协调？有没有某种方法可以将输出更改为RDTSC，这样我就可以使用它，或者有没有一个系统调用可以让我获得与要跟踪的输出相同的时间？提前感谢您的帮助。
RDTSC不是一个流行的指令。使用它时会出现一些问题，一些事件（如hybernation）会重置计数器。其他常见的问题来源是动态CPU时钟。有很好的帖子比较rdtsc和hpet:
http://aufather.wordpress.com/2010/09/08/high-performance-time-measuremen-in-linux/
为了检查rdtsc的准确性，我测量了它在一秒钟内计数的时钟周期，并将其与声明的cpu时钟进行比较。它只能在禁用CPU动态时钟的情况下工作。参见：
https://github.com/petersenna/rdtscbench
因此，在查看源代码后，我发现在某一点上，代码采用RDTSC值，并对其进行了一些奇特的计算，试图将其乘以时钟频率，并添加一些启动时计算的偏移量。然而，这个代码似乎有点过时了，因为RDTSC保证在新芯片上的核心之间是一致的，而这是假设每个核心都不同。它似乎也在收集当前频率，而不是最大频率，这似乎是文件中所说的RDTSC使用的频率。
因此，在这一点上，在我的例子中有用的准确度水平上，时间似乎与实际时间不直接相关。希望这个错误在即将发布的内核版本中得到修复，并为我同步这两个集打开机会，但在那之前，它似乎不够可靠。