> On Fri, Oct 29, 1999 at 12:20:32PM -0700, Jeremy Fitzhardinge wrote:
> > Bogomips calculation is pretty slow and CPU consuming. The basic problem is
> > that the premise, the CPU always runs at the same rate, is flawed. The
> > solution is to find some other timebase.
>
>
> I think Jeremy's on the right track. Processor speed is too fickle[1] and
> bogomip re-calculation too expensive (and ugly) to keep.
No, bogomip calculation is too expensive to do during a running kernel. At
boot time it doesn't matter one whit what it costs.
> Unfortunately, I don't see a truly portable way to do it. CPUs exist on
> every machine (presumably!), and RTC doesn't. *sigh*
>
> So, referring to the wrong track, if we accept there's no other timebase
> method, then we might (and I'm talking out of my hat, here) better control
> the APM hardware to detect what it intends to do to the system, and adjust
> our bogomip constant with a multiplier.
>
> If that's not possible for some probably obvious reason, feel free to
> flame me.
No, that's it exactly. Some questions:
Given:
If we know the frequencies the amchine runs at in each mode, it's no big
deal to find the new bogomips.
Then:
Is that something we can find quicker than a full on bogo mips calc? How?
Would laptops need a bogomips.conf file in their /etc directory, or do APM
and what not have an API that can tell us that on most systems that change
clock speed? Or is there a super fast and dirty check we can do to "guess"
from a group of logical speeds which one we're running.
If none of those work, could we do a super quick and dirty compute to guess
what speed we're going? (I.e. do most of these systmes just shut down the
front side bus, or only the CPU side of it by changing the multiplier?
How expensive is a bogomips calc anyway?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/