Re: [RFC][PATCH] clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()

From: Mike Galbraith
Date: Tue Mar 04 2014 - 21:56:43 EST


On Wed, 2014-03-05 at 08:58 +0800, John Stultz wrote:
> On Tue, Mar 4, 2014 at 3:10 PM, Mike Galbraith <bitbucket@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxx>
> >> > Cc: John Stultz <john.stultz@xxxxxxxxxx>,
> >> > Signed-off-by: Mike Galbraith <bitbucket@xxxxxxxxx>
> >>
> >> 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

--
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/