BogoMIPS

Has anyone else noticed BogoMIPS is zero? Are we not doing the calibrate delay?

Greg Weeks

-bash-2.05b# cat /proc/cpuinfo
system type : MIPS Malta
processor : 0
cpu model : MIPS 4Kc V0.1
BogoMIPS : 0.00
wait instruction : yes
microsecond timers : yes
tlb_entries : 16
extra interrupt vector : yes
hardware watchpoint : yes
VCED exceptions : not available
VCEI exceptions : not available
-

Probably, because it's no longer relevant these days. It doesn't say anything special.

-- <http://www.linux-mips.org/wiki/index.php/BogoMIPS>

Interestingly, my IP28 still shows the BogoMIPS reading in /proc/cpuinfo:

So honestly, I don't know what's happening with BogoMIPS. :-) What I do know however, it isn't worth a cracker in terms of benchmarking value. ;-)

--

+-------------------------------------------------------------+
| Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org |
| Atomic Linux Project     -oOo-    http://atomicl.berlios.de |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
| I haven't lost my mind - it's backed up on a tape somewhere |
+-------------------------------------------------------------+

I could care less about it as a benchmarking value, but it's used to do calibrated udelays. If mips doesn't need it because it calibrates some other way then fine. I suspect not though and we're probably using an initial works everywhere value. I don't know though.

Greg Weeks

The bugs is the result of the somewhat messy way the calibration code is working. calibrate_delay() puts it's result into a global variable, loops_per_jiffy. The value is CPU-specific not global, so we need to copy it to a per-processor data structure which we do on SMP but forget to do on uniprocessor. At the same time the actual delay loop code in delay.h knew to use loops_per_jiffy on uniprocessor, so it was actually working ok.

Ralf

Index: arch/mips/kernel/cpu-probe.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/cpu-probe.c,v retrieving revision 1.43

diff -u -r1.43 cpu-probe.c
@@ -17,7 +17,6 @@
 #include <linux/ptrace.h>
 #include <linux/stddef.h>
 
-#include <asm/bugs.h>
 #include <asm/cpu.h>
 #include <asm/fpu.h>
 #include <asm/mipsregs.h>

Index: arch/mips/kernel/smp.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/smp.c,v retrieving revision 1.77

diff -u -r1.77 smp.c
@@ -226,7 +226,6 @@
 /* called from main before smp_init() */
 void __init smp_prepare_cpus(unsigned int max_cpus)
 {
-	cpu_data[0].udelay_val = loops_per_jiffy;
 	init_new_context(current, &init_mm);
 	current_thread_info()->cpu = 0;
 	smp_tune_scheduling();

Index: include/asm-mips/bugs.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/bugs.h,v retrieving revision 1.10

diff -u -r1.10 bugs.h
@@ -8,12 +8,17 @@
 #define _ASM_BUGS_H
 
 #include <linux/config.h>
+#include <asm/cpu.h>
+#include <asm/cpu-info.h>
 
 extern void check_bugs32(void);
 extern void check_bugs64(void);
 
 static inline void check_bugs(void)
 {
+	unsigned int cpu = smp_processor_id();
+
+	cpu_data[cpu].udelay_val = loops_per_jiffy;
 	check_bugs32();
 #ifdef CONFIG_MIPS64
 	check_bugs64();

Index: include/asm-mips/delay.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/delay.h,v retrieving revision 1.16

diff -u -r1.16 delay.h
@@ -15,8 +15,6 @@
 
 #include <asm/compiler.h>
 
-extern unsigned long loops_per_jiffy;
-
 static inline void __delay(unsigned long loops)
 {
 	if (sizeof(long) == 4)

@@ -82,11 +80,7 @@
 	__delay(usecs);
 }
 
-#ifdef CONFIG_SMP
 #define __udelay_val cpu_data[smp_processor_id()].udelay_val
-#else
-#define __udelay_val loops_per_jiffy
-#endif
 
 #define udelay(usecs) __udelay((usecs),__udelay_val)
 

Nonsense. It's just not printed to the screen by default.

Because you're running a vintage kernel. The 0 BogoMIPS bug was introduced by this CVS change:

revision 1.54
date: 2005/02/21 21:34:24; author: ralf; state: Exp; lines: +2 -2 On multiprocessor systems the BogoMIPS for each CPU was reported was the value for the last CPU having calibrated it's delay loop.

Only the value shown in /proc/cpuinfo on UP kernel was affected, so the effect should be purely psychologic - I know what negative impact low BogoMIPS may have on some people ;-)

Ralf