Re: [PATCH]: fix 32bits integer overflow in loops_per_jiffy calculation

[Gabriel Paubert <paubert@iram.es>]

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.