Messages in this thread | | | From | Benjamin Herrenschmidt <> | Subject | Re: [PATCH]: fix 32bits integer overflow in loops_per_jiffy calculation | Date | Thu, 22 Aug 2002 15:00:26 +0200 |
| |
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.
- 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/
| |