[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALAqxLUeb2GuPyULnHL+FHgbdanVxz2JsvD2O0bJWKyN=CJ3UQ@mail.gmail.com>
Date: Tue, 4 Mar 2014 14:40:20 +0800
From: John Stultz <john.stultz@...aro.org>
To: Mike Galbraith <bitbucket@...ine.de>
Cc: LKML <linux-kernel@...r.kernel.org>,
"Cc: Salman Qazi" <sqazi@...gle.com>
Subject: Re: [RFC][PATCH] clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()
On Tue, Mar 4, 2014 at 1:38 PM, Mike Galbraith <bitbucket@...ine.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@...gle.com>
> Cc: John Stultz <john.stultz@...aro.org>,
> Signed-off-by: Mike Galbraith <bitbucket@...ine.de>
Thanks for sending this in! Curious exactly how the issue was being
triggered? To some extent the cyclecounter/timecounter code never got
the adoption I expected, so I've sort of had it on my list to see
about killing that code off and merging its users w/ clocksources
(since the clocksource has been simplified since cyclecounters
landed). So curious to see what its actually being used for..
particularly since the timecounter code does have accumulation logic
which should avoid overflows (and deal with hardware counters that
wrap).
I'll put this in my 3.15 queue.
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists