On Wed, 2014-03-05 at 08:58 +0800, John Stultz wrote: > On Tue, Mar 4, 2014 at 3:10 PM, Mike Galbraith <[email protected]> wrote: > > On Tue, 2014-03-04 at 14:40 +0800, John Stultz wrote: > >> On Tue, Mar 4, 2014 at 1:38 PM, Mike Galbraith <[email protected]> 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 <[email protected]> > >> > Cc: John Stultz <[email protected]>, > >> > Signed-off-by: Mike Galbraith <[email protected]> > >> > >> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
