Messages in this thread |  | | From | Benjamin Herrenschmidt <> | Subject | Re: [PATCH]: fix 32bits integer overflow in loops_per_jiffy calculation | Date | Thu, 22 Aug 2002 16:31:15 +0200 |
| |
>Well, first on sane archs which have an easily accessible, fixed >frequency time counter, loops_per_jiffy should never have existed :-) > >Second, putting this code there means that one day somebody will >inevitably try to use it outside of its domain of operation (like it >happened for div64 a few months ago when I pointed out that it would not >work for divisors above 65535 or so).
Well... it's clearly located inside kernel/cpufreq.c, so there is little risk, though it may be worth a big bold comment
>Finally, I agree that we should not import libgcc, but for example on >PPC32 the double lengths shifts (__ashrdi3, __ashldi3, and __lshsldi3) >are implemented somewhere, and the assembly implementation (directly >taken from some appendix in PPC documentation, I just slightly twisted >__ashrdi3 to make it branchless AFAIR) is actually way faster than the >one in libgcc ;-), and less than half the size. > > Adding a few subroutines that implement a subset of libgcc's >functionality is necessary for most archs (which functions are needed is >arch, and sometimes compiler's, dependent). > >In this case a generic scaling function, while not a standard libgcc/C >library feature has potentially more applications than this simple >cpufreq approximation. But I don't see very much the need for scaling a >long (64 bit on 64 bit archs) value, 32 bit would be sufficient.
Well... if you can write one, go on then ;) In my case, I'm happy with Yoann implementation for cpufreq right now. Though I agree that could ultimately be moved to arch code.
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/
|  |