Yoann Vandoorselaere wrote:
> Hi,
>
> The "low_part * mult" multiplication of the old function may overflow a
> 32bits integer...
>
> This patch both fix the overflow issue (tested with frequencies up to
> 20Ghz), and make the result of the function lose less precision.
>
> Please apply,
>
>
>
> ------------------------------------------------------------------------
>
> --- linux-benh/kernel/cpufreq.c 2002-08-21 17:27:52.000000000 +0200
> +++ linux-yoann/kernel/cpufreq.c 2002-08-22 11:27:09.000000000 +0200
> @@ -78,14 +78,16 @@ static unsigned int cpufreq_
> */
> static unsigned long scale(unsigned long old, u_int div, u_int mult)
> {
> - unsigned long low_part, high_part;
> -
> - high_part = old / div;
> - low_part = (old % div) / 100;
> - high_part *= mult;
> - low_part = low_part * mult / div;
> -
> - return high_part + low_part * 100;
> + unsigned long val, carry = 0;
> +
> + mult /= 100;
> + div /= 100;
if(abs(div)<100) div=0;
> + val = old / div * mult;
Now happily divide by zero.
> +
> + carry = old % div;
Again.
> + carry = carry * mult / div;
Again.
> +
> + return val + carry;
> }
>
And I can't see how it can be more precise, you divide the numerator and
denominator of the fraction by 100 and then proceed forgetting
everything about the rest. Basically this looses about 7 bits of precision.
Now altogether I believe that such a function pertains to a per arch
optimized routine.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Aug 23 2002 - 22:00:24 EST