From: Mike Galbraith <bitbucket@online.de>
To: John Stultz <john.stultz@linaro.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
"Cc: Salman Qazi" <sqazi@google.com>
Subject: Re: [RFC][PATCH] clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()
Date: Wed, 05 Mar 2014 03:56:31 +0100 [thread overview]
Message-ID: <1393988191.5392.8.camel@marge.simpson.net> (raw)
In-Reply-To: <CALAqxLVkDQO8nhFiX3avZ_dGyqH+uXCwLDzEMJbjp4i54Q9KaA@mail.gmail.com>
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
next prev parent reply other threads:[~2014-03-05 2:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-04 5:38 [RFC][PATCH] clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns() Mike Galbraith
2014-03-04 6:40 ` John Stultz
2014-03-04 7:10 ` Mike Galbraith
2014-03-05 0:58 ` John Stultz
2014-03-05 2:56 ` Mike Galbraith [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-03-04 5:20 Mike Galbraith
2014-03-04 7:20 ` Henrik Austad
2014-03-04 7:31 ` Mike Galbraith
2014-03-04 7:36 ` Mike Galbraith
2014-03-04 8:02 ` Henrik Austad
2014-03-04 8:24 ` Mike Galbraith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1393988191.5392.8.camel@marge.simpson.net \
--to=bitbucket@online.de \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sqazi@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox