Messages in this thread | | | Subject | Re: [RFC][PATCH] clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns() | From | Mike Galbraith <> | Date | Wed, 05 Mar 2014 03:56:31 +0100 |
| |
On Wed, 2014-03-05 at 08:58 +0800, John Stultz wrote: > On Tue, Mar 4, 2014 at 3:10 PM, Mike Galbraith <bitbucket@online.de> wrote: > > On Tue, 2014-03-04 at 14:40 +0800, John Stultz wrote: > >> On Tue, Mar 4, 2014 at 1:38 PM, Mike Galbraith <bitbucket@online.de> wrote: > >> > (crap crap crap... M.A.I.N.T.A.I.N.E.R.S _dummy_) > >> > > >> > clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns() > >> > > >> > As per 4cecf6d401a "sched, x86: Avoid unnecessary overflow in sched_clock", > >> > cycles * mult >> shift is overflow prone. so give it the same treatment. > >> > > >> > Cc: Salman Qazi <sqazi@google.com> > >> > Cc: John Stultz <john.stultz@linaro.org>, > >> > Signed-off-by: Mike Galbraith <bitbucket@online.de> > >> > >> Thanks for sending this in! Curious exactly how the issue was being > >> triggered? > > > > Dunno that it is. This is the result of me rummaging around, looking > > for any excuse what-so-ever for a small and identical group of weird a$$ > > boxen running old 2.6.32 kernels (w. 208 day fix!) to manage to hop back > > and forth in time by exactly 208 days. Grep showed me that function, so > > I scurried off and swiped the fix. > > So.. this makes me a bit more hesitant to really queue this, > particularly since the timecounter logic is supposed to periodically > accumulate cycles so you don't run into these overflow issues (the > earlier fix was for sched_clock which didn't do any accumulation).
Ok.
> So, if you're seeing time jump around, that's probably clocksource or > timekeping related, and not tied to the cyclecounter code. Do you have > any other info about these systems? What clocksource are they using, > etc?
Not much, clocksource is TSC, with CPUs that should make it reliable. They're interested now, so I'll be hearing more digging more.
-Mike
| |