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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.