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

[Benjamin Herrenschmidt]

Hi Gabriel !

>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;
>>  }

None of the above can happen in the domain of application of this
function. It's used to scale up/down the loops_per_jiffy value when
scaling the CPU frequency. Anyway, the above isn't worse than the
original function. Ideally, we would want 64 bits arithmetics, but
we decided long ago not to bring the libcc support routines for that
in the kernel.
>
>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.

Which is mostly ok for what we need. I think Yoann didn't mean it's
more precise that what it replace, but rather more precise than his
original implementation that divided by 1000 ;) Anyway, it's not
significantly worse than what we had and won't overflow as easily
which is all we want for this routine now.

>Now altogether I believe that such a function pertains to a per arch 
>optimized routine.

Maybe... though in the context of cpufreq, it may not make that much
sense.

Ben.