2009/7/9 Andriy Gapon <avg_at_freebsd.org>: > > > There are at least the following two alternatives: > > 1. Keep things as they are and warn users not to change CPU clock frequency when > they use DTrace and the CPU doesn't have invariant TSC. I think that this should > cause only minor inconveniences to a portion of DTrace users. > > 2. Use raw TSC value as a DTrace timestamp and document this difference from the > original DTrace. Advantage: timestamp value is always monotonic. Disadvantage: > manual conversion is needed to get "real" time (using the same formula). > Please note that in this case timestamps would be in non-linear time dimension if > TSC frequency changes, so to get meaningful timestamps (when needed/important) one > would still have to make sure that TSC frequency stay constant. > According to wikipedia newer Intel processors have a constant rate TSC whos freq does not change. If this features is available on most processors today, then I am happy to stick with option 1. Another problem with this is that on a multicore machine each core may have different TSC values. Has anyone thought how to address this issue? Could we calculate the offset of each core from core0, and then ensure the offset is applied to the tsc value when it is needed? thanks AndrewReceived on Thu Jul 09 2009 - 20:26:15 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:51 UTC