Messages in this thread | | | Date | Mon, 01 Apr 2013 15:16:10 -0700 | From | John Stultz <> | Subject | Re: [PATCH] timekeeping: Add tracepoints for xtime changes - v2 |
| |
On 04/01/2013 02:58 PM, David Ahern wrote: > On 4/1/13 12:55 PM, John Stultz wrote: > >> This all looks reasonable. Though do we need to be more explicit in what >> we're tracing here? ie: CLOCK_REALTIME timestamps? > > The tracepoints don't care about the what and the tp names follow the > convention of trace_<function_name> so you know where it is triggering. > >> >> I'd someday eventually like to rework the timekeeping core to be mostly >> ktime_t based, building time in a more logical method up from >> CLOCK_MONOTONIC rather then using CLOCK_REALTIME as our base and >> subtracting time from that. I'm just worried about what sort of >> constraints these tracepoints may put on a larger rework in the future. > > Understood. And my comment above is not going to help -- ie., telling > perf specific tracepoints which include function names. Should I > consolidate this into a single trace_tod_update() that gets invoked in > various places? The locations can move without affecting perf. I just > want the tod update; where it happens should not matter. >
I guess what I'm getting at is: What ABI are we creating here? Can these tracepoints come and go without any consequence? Or would changing them in the future cause application breakage?
I'm somewhat worried even trace_tod_update() is maybe too vague (again not that the name specifically is critical, but that the semantics we're specifying are clear). In other words, I think you're wanting a tracepoint at any time CLOCK_REALTIME is updated by anything other then the normal progression of time? Is that right?
You may want to also include the leapsecond modification in the tracing as well.
thanks -john
| |