BogoMIPS

BogoMIPS

[Greg Weeks]

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
-

Re: BogoMIPS

[Stuart Longland]

[-- Attachment #1: Type: text/plain, Size: 2267 bytes --]

Greg Weeks wrote:
> 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.

> The more surprising it is that BogoMIPS have become a benchmark for
 > performance as important as extra inches in spam email.  Having been
 > a permanent annoynce over the years due to miss-interpretation by
 > users and due to excessive output on multiprocessor machines Linux
 > by default will no longer print the BogoMIPS number since 2.6.9-rc2.
-- <http://www.linux-mips.org/wiki/index.php/BogoMIPS>

Interestingly, my IP28 still shows the BogoMIPS reading in /proc/cpuinfo:
> stuartl@indigo ~ $ uname -a
> Linux indigo 2.6.10-mipscvs-20050115-ip28 #2 Sun Apr 3 08:24:18 EST 2005 mips64 R10000 V2.5  FPU V0.0 SGI Indigo2 GNU/Linux
> stuartl@indigo ~ $ cat /proc/cpuinfo
> system type             : SGI Indigo2
> processor               : 0
> cpu model               : R10000 V2.5  FPU V0.0
> BogoMIPS                : 193.53
> wait instruction        : no
> microsecond timers      : yes
> tlb_entries             : 64
> extra interrupt vector  : no
> hardware watchpoint     : yes
> VCED exceptions         : not available
> VCEI exceptions         : not available
> stuartl@indigo ~ $

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 |
+-------------------------------------------------------------+

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: BogoMIPS

[Greg Weeks]

Stuart Longland wrote:

>
> 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. 
> ;-)

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

Re: BogoMIPS

[Ralf Baechle]

On Wed, Apr 13, 2005 at 07:36:40AM -0400, Greg Weeks wrote:

> >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. 
> >;-)
> 
> 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.

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
--- arch/mips/kernel/cpu-probe.c	8 Apr 2005 20:36:05 -0000	1.43
+++ arch/mips/kernel/cpu-probe.c	13 Apr 2005 13:19:11 -0000
@@ -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
--- arch/mips/kernel/smp.c	18 Mar 2005 17:36:53 -0000	1.77
+++ arch/mips/kernel/smp.c	13 Apr 2005 13:19:11 -0000
@@ -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
--- include/asm-mips/bugs.h	25 Jul 2003 22:49:24 -0000	1.10
+++ include/asm-mips/bugs.h	13 Apr 2005 13:19:12 -0000
@@ -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
--- include/asm-mips/delay.h	8 Oct 2004 02:41:17 -0000	1.16
+++ include/asm-mips/delay.h	13 Apr 2005 13:19:12 -0000
@@ -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)
 

Re: BogoMIPS

[Ralf Baechle]

On Wed, Apr 13, 2005 at 02:19:11PM +1000, Stuart Longland wrote:

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

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

> Interestingly, my IP28 still shows the BogoMIPS reading in /proc/cpuinfo:
> >stuartl@indigo ~ $ uname -a
> >Linux indigo 2.6.10-mipscvs-20050115-ip28 #2 Sun Apr 3 08:24:18 EST 2005 

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

bogomips

[Mike Shaver]

Like, duh.
Forgot to add the routing info to the startup bits, so only systems on
the same net could see it.

Since neon's one of them, I didn't notice before.

It's back now, for those who care.

Mike

-- 
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation 
#>              Commando Developer - Whatever It Takes
#>                                                                     
#> "See, you not only have to be a good coder to create a system like
#>    Linux, you have to be a sneaky bastard too." - Linus Torvalds

bogomips

[Mike Shaver]

is back.

(The electrician has been and gone, and bogomips is now UPS'd as
well.)

Mike

-- 
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation 
#>      Chief System Architect -- will tame sendmail(8) for food       
#>                                                                     
#> "You are a very perverse individual, and I think I'd like to get to 
#>  know you better." --- eric@reference.com