Re: [Query/tick] Are we enqueing 'tick-sched' hrtimers in past ?

[Viresh Kumar]

On 3 July 2014 19:29, Steven Rostedt <rostedt@xxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/