> On Sat, 30 Oct 1999, Chad Miller wrote:
>
> > 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
yes and no. It is probably too expensive to run every minute - yes.
But it takes less time than initialization of scsi bus (that happens after
you do insmod or some error occurs).
Face it - changing cpu speed is a _change_ in system configuration.
Also can someone remind me what rdtsc does ? I thought it counted clock
cycles. The point of bogomips calculation is to find out how many cycles
in a second there really are.
The other clock source might be memory bus - anyone heard of memory bus
changing speed on the fly ?
Vladimir Dergachev
> 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/
>
-
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/