On 3 July 2014 19:29, Steven Rostedt rostedt@goodmis.org wrote:
Unless you changed clocks, the default timing of the trace is done by
I haven't..
trace_clock_local() which basically just calls sched_clock(). Not much to be fixed there.
Okay.
I would be interested in seeing another hrtimer_expire_entry to see if that is off by anything else other than 10ms. As that event is the only one shown to show what hrtimer thinks "now" is.
I checked that for some other timer and it was still 10ms. So, its not a tick-sched issue.
Also, I'm not really seeing what is wrong with the above. The expire_entry means the timer is being triggered and it raised the softirq. The hrtimer_start is a new setting to go off at 149.745. Since you noticed that the trace time stamp is 10ms ahead, that would state that the hrtimer would go off around trace timestamp 149.755.
The only part that looked odd to me was this offset of 10ms.
The trace timer stamp uses a different clock than hrtimers does. Do not confuse them as the same clock.
Hmm, that's new. And the diff might be ~10ms
The best you can do is reference that "now" value to get the difference between the two and use that as a reference for what the time stamp of the trace should be when the hrtimer goes off again.
Yeah, it was on time as this 10ms offset was consistent ..
So, there is no problem in traces apart from the fact that people might try to match trace-time and hrtimer time, like I did.
But the other issue I reported in hrtimer/tick-sched code might still be valid.
Thanks for your reply.
-- viresh