[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAL1RGDV_f8_sDMrK6rUq1P-xh-=E0xwphPo0bQ6tHSnJk6JQmw@mail.gmail.com>
Date: Tue, 4 Dec 2018 11:33:43 -0800
From: Roland Dreier <roland@...estorage.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: john.stultz@...aro.org, sboyd@...nel.org,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] clocksource: Add heuristics to avoid switching away from
TSC due to timer delay
> /*
> * Proper multiline comments look like this not like
> * the above.
> */
Got it, will fix next time around.
> That aside. Why are you trying to do heuristics on the delta?
>
> We have way better information than that. The watchdog timer expiry time is
> known and we can determine the exact delay of the timer.
>
> The watchdog clocksource provides the maximum 'idle' time, i.e. the time
> between two reads, in clocksource::max_idle_ns. That value is filled in
> when the clocksource is configured.
>
> So without doing speculation we can make an informed decision:
>
> elapsed = jiffies_to_nsec(jiffies - watchdog_timer->expires) +
> WATCHDOG_INTERVAL_NS;
>
> if (elapsed > wdcs->max_idle_ns) {
> Skip ......
> }
Yes, that makes more sense than what I was doing, although I'm not
sure on the details. Just missed that idea.
Why are you adding the watchdog interval to the calculated elapsed
time? It seems we have an issue exactly if jiffies -
watchdog_timer->expires is too big, without adding the interval we
tried to wait in on top. Also I think we might want to be careful
that jiffies is >= the expires time - or is it not possible that a
timer fires one jiffy early?
Also for full generality it seems we should check against the
clocksource max_idle_ns as well - for x86 TSC is wider than HPET but
there may be other architectures that could hit the same problem, just
with the clocksource being checked wrapping around instead of the
watchdog clocksource. Right?
Thanks!
Roland
Powered by blists - more mailing lists