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

[John Stultz]

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).

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?

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