Re: zeroing pages in the idle task?

"Timothy A. Seufert" [off-list ref] writes:

At 9:35 PM -0500 9/14/00, Takashi Oe wrote:

quoted

On Wed, 13 Sep 2000, Geert Uytterhoeven wrote:

quoted

 On the m68k, we have some code to guestimate the CPU clock based on the
 BogoMIPS (see get_cpuinfo() in arch/m68k/kernel/setup.c). Since we
 didn't care about the overhead incurred by interrupt processing, it's
 not that accurate though (I get 24.8 MHz on my 25 MHz 68040).

That thought had occured to me.  Only problem is that the relationship
between bogomips and cpu clock speed depends on, well, CPU.  For 601, it's
one to one, and, for 604, two to one, and so on.  I don't know the ratios
for 603, G3, or G4.

It gets more fun than that.  I've found that the G3's ratio varies
depending on how many of its features are turned on.  It's usually
2:1, but if the BTIC and BHT (Branch Target Instruction Cache, Branch
History Table) are turned off, it drops way down (1:1 I think, but I
may be misremembering).

Would a rewrite of the bogomips loop be an option?

In that case one could chose a sequence of dependant instructions in
the loop body, preventing possible superscalar execution. (One could
specifically use instructions that are commonly 'execution
serializing', like 'adde', to again enforce execution of only a single
instruction per clock.)

If the loop body was long enough, effects of varying branching
efficiency could also be masked. That way, bogomips should correlate
very well with actual MHz.

  Holger

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Would a rewrite of the bogomips loop be an option?

Not really. The bogomips loop is meant to calibrate short delay loops used
elsewhere in the kernel.

You can always add another calibration loop for the MHz if you absolutely
need to.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Fri, 15 Sep 2000, Michael Schmitz wrote:

quoted

Would a rewrite of the bogomips loop be an option?

Not really. The bogomips loop is meant to calibrate short delay loops used
elsewhere in the kernel.

You can always add another calibration loop for the MHz if you absolutely
need to.

Using the bogomips as it is is cheap, so I think I'll code up with that
and add "(maybe wrong by 1 MHz or more)" or something for /proc/cpuinfo's
clock field.  Or remove that field all together where the information is
not readily available.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/