linux-mips
[Top] [All Lists]

Re: [PATCH] MIPS: Octeon: Use non-overflowing arithmetic in sched_clock

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH] MIPS: Octeon: Use non-overflowing arithmetic in sched_clock
From: David Daney <ddaney@caviumnetworks.com>
Date: Mon, 11 Jan 2010 09:28:23 -0800
Cc: linux-mips@linux-mips.org
In-reply-to: <20100111102023.GE13886@linux-mips.org>
References: <1262990856-8300-1-git-send-email-ddaney@caviumnetworks.com> <20100111102023.GE13886@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 2.0.0.21 (X11/20090320)
Ralf Baechle wrote:
On Fri, Jan 08, 2010 at 02:47:36PM -0800, David Daney wrote:

With typical mult and shift values, the calculation for Octeon's
sched_clock overflows when using 64-bit arithmetic.  Use 128-bit
calculations instead.

Applied though my first thought whenever I see extended precission math
is gross - maybe we're going to find a better solution.  Hopefully!

  Ralf

I did have some apprehension myself.  However consider:

* For an 800MHz core clock, clocksource_set_clock() generates a shift value of 31. This leads to overflow of 64-bit arithmetic approximately every 8 seconds. This specific case could be reduced to a 2 bit shift, resulting in time to overflow of more than 100 years. But one can imagine clock rates that would require large shifts.

* We need to return a 64-bit clock value, this will overflow in about 500 years, Unless we are very careful with our arithmetic, we risk overflow in unacceptable short time periods.

* This is octeon specific and the 128-bit operation is cheap. Probably cheaper than accounting for overflows in 64-bit arithmetic.

David Daney

<Prev in Thread] Current Thread [Next in Thread>