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