[lkml]   [2002]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH]: fix 32bits integer overflow in loops_per_jiffy calculation
    Hi Gabriel !

    >if(abs(div)<100) div=0;
    >> + val = old / div * mult;
    >Now happily divide by zero.
    >> +
    >> + carry = old % div;
    >> + carry = carry * mult / div;
    >> +
    >> + 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


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:28    [W:0.037 / U:1.448 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site