On 12/11/2013 04:07 AM, Ingo Molnar wrote: > * John Stultz <john.stu...@linaro.org> wrote: > >> [...] >> >> I'd much rather see perf export CLOCK_MONOTONIC_RAW timestamps, >> since that clockid is well defined. [...] > So the problem with that clock is that it does the following for every > timestamp: > > cycle_now = clock->read(clock); > > ... which is impossibly slow if something like the HPET is used, which > is rather common - so this is a non-starter to timestamp perf events > with. We use the scheduler clock as a reasonable compromise between > scalability and clock globality. > > I can see two solutions: > > 1) > > One approach is what I described in my other reply a few minutes ago: > track the flow of GTOD, timestamped with the fast perf timestamps, so > that GTOD can be correlated to the perf clock, if user-space so > wishes. The correlation is simple so this gets close to the ease of > use of being able to timestamp GTOD directly. > > (That would be useful for other purposes as well, such as > instrumenting GTOD updates.) > > 2) > > An alternate, rather interesting approach would be to change the > scheduler clock offset to be influenced by the above events, so that > it quasi-approximates GTOD and emits natural time of day timestamps. > > This already happens partially in the sched-clock slow path, > kernel/sched/clock.c's sched_clock_local(), it uses scd->tick_gtod > timestamps to correlate to the monotonic clock. This could be changed > over to use not get_ktime() but getnstimeofday(), to get true TOD > timestamps. > > The trickier bit is the x86 fast-path, in arch/x86/kernel/tsc.c's > native_sched_clock(). That relies on __cycles_2_ns() to transform a > CPU cycles timestamp into (boot time offset) nanoseconds. For that it > uses the cyc2ns_offset percpu variable. That variable could be updated > periodically so that it's TOD offset. > > My (strong!) preference would be #2, for the simple reason that it > would make perf timestamps instantly usable and tooling wouldn't have > to do anything to get true timestamps.
Right. #2 is basically what I was (probably poorly) trying to describe as my ideal solution, making perf export what is essentially CLOCK_MONOTONIC_RAW time (using CLOCK_MONOTONIC_RAW is more likely to be easier to match then CLOCK_REALTIME/getnstimeofday(), since you don't have to deal with anyone setting the clock, or frequency adjustments from NTP). thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
