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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKohpokj3nop9OKAmK386ofs4FM_KhjpLD+xz5Hf4gz+gp5dgA@mail.gmail.com>
Date:	Thu, 3 Jul 2014 20:12:18 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Preeti U Murthy <preeti@...ux.vnet.ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
	Linaro Networking <linaro-networking@...aro.org>,
	Kevin Hilman <khilman@...aro.org>
Subject: Re: [Query/tick] Are we enqueing 'tick-sched' hrtimers in past ?

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