linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFT] Port 0x80 I/O speed
@ 2007-12-11 23:31 Rene Herman
  2007-12-11 23:40 ` Maxim Levitsky
                   ` (24 more replies)
  0 siblings, 25 replies; 68+ messages in thread
From: Rene Herman @ 2007-12-11 23:31 UTC (permalink / raw)
  To: Linux Kernel
  Cc: dpreed, Alan Cox, pavel, andi, rol, Krzysztof Halasa, david, hpa,
	john, linux-os

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

Good day.

Would some people on x86 (both 32 and 64) be kind enough to compile and run 
the attached program? This is about testing how long I/O port access to port 
0x80 takes. It measures in CPU cycles so CPU speed is crucial in reporting.

Posted a previous incarnation of this before, buried in the outb 0x80 thread 
which had a serialising problem. This one should as far as I can see measure 
the right thing though. Please yell if you disagree...

For me, on a Duron 1300 (AMD756 chipset) I have a constant:

rene@7ixe4:~/src/port80$ su -c ./port80
cycles: out 2400, in 2400

and on a PII 400 (Intel 440BX chipset) a constant:

rene@6bap:~/src/port80$ su -c ./port80
cycles: out 553, in 251

Results are (mostly) independent of compiler optimisation, but testing with 
an -O2 compile should be most useful. Thanks!

Rene.

[-- Attachment #2: port80.c --]
[-- Type: text/plain, Size: 1138 bytes --]

/* gcc -W -Wall -O2 -o port80 port80.c */

#include <stdlib.h>
#include <stdio.h>

#include <sys/io.h>

#define LOOPS 10000

inline unsigned long long rdtsc(void)
{
	unsigned long long tsc;

	asm volatile ("rdtsc": "=A" (tsc));

	return tsc;
}

inline void serialize(void)
{
	asm volatile ("cpuid": : : "eax", "ebx", "ecx", "edx");
}

int main(void)
{
	unsigned long long start;
	unsigned long long overhead; 
	unsigned long long output;
	unsigned long long input;
	int i;

	if (iopl(3) < 0) {
		perror("iopl");
		return EXIT_FAILURE;
	}

	asm volatile ("cli");
	start = rdtsc();
	for (i = 0; i < LOOPS; i++) {
	 	serialize();	
		serialize();
	}
	overhead = rdtsc() - start;

	start = rdtsc() + overhead;
	for (i = 0; i < LOOPS; i++) {
		serialize();
		asm volatile ("outb %al, $0x80");
		serialize();
	}
	output = rdtsc() - start;

	start = rdtsc() + overhead;
	for (i = 0; i < LOOPS; i++) {
		serialize();
		asm volatile ("inb $0x80, %%al": : : "al");
		serialize();
	}
	input = rdtsc() - start;
	asm volatile ("sti");

	output /= LOOPS;
	input  /= LOOPS;
	printf("cycles: out %llu, in %llu\n", output, input);

	return EXIT_SUCCESS;
}

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
@ 2007-12-11 23:40 ` Maxim Levitsky
  2007-12-11 23:44   ` Rene Herman
  2007-12-11 23:43 ` Alejandro Riveira Fernández
                   ` (23 subsequent siblings)
  24 siblings, 1 reply; 68+ messages in thread
From: Maxim Levitsky @ 2007-12-11 23:40 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On Wednesday 12 December 2007 01:31:18 Rene Herman wrote:
> Good day.
> 
> Would some people on x86 (both 32 and 64) be kind enough to compile and run 
> the attached program? This is about testing how long I/O port access to port 
> 0x80 takes. It measures in CPU cycles so CPU speed is crucial in reporting.
> 
> Posted a previous incarnation of this before, buried in the outb 0x80 thread 
> which had a serialising problem. This one should as far as I can see measure 
> the right thing though. Please yell if you disagree...
> 
> For me, on a Duron 1300 (AMD756 chipset) I have a constant:
> 
> rene@7ixe4:~/src/port80$ su -c ./port80
> cycles: out 2400, in 2400
> 
> and on a PII 400 (Intel 440BX chipset) a constant:
> 
> rene@6bap:~/src/port80$ su -c ./port80
> cycles: out 553, in 251
> 
> Results are (mostly) independent of compiler optimisation, but testing with 
> an -O2 compile should be most useful. Thanks!
> 
> Rene.
> 


Sure,

maxim@MAIN:~/tmp$ sudo ./port800
cycles: out 1767, in 1147
maxim@MAIN:~/tmp$ sudo ./port800
cycles: out 1774, in 1148
maxim@MAIN:~/tmp$ sudo ./port800
cycles: out 1769, in 1150
maxim@MAIN:~/tmp$ sudo ./port800
cycles: out 1769, in 1150
maxim@MAIN:~/tmp$ sudo ./port800
cycles: out 1777, in 1150
maxim@MAIN:~/tmp$ sudo ./port800
cycles: out 1766, in 1149
maxim@MAIN:~/tmp$ sudo ./port800
cycles: out 1768, in 1148
maxim@MAIN:~/tmp$ sudo ./port800
cycles: out 1765, in 1147


Core 2 Duo system (ICH8/Intel DG965RY motherboard)

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
  2007-12-11 23:40 ` Maxim Levitsky
@ 2007-12-11 23:43 ` Alejandro Riveira Fernández
  2007-12-11 23:51   ` Rene Herman
       [not found]   ` <Pine.LNX.4.61.0712120753210.4443@chaos.analogic.com>
  2007-12-11 23:55 ` Nigel Cunningham
                   ` (22 subsequent siblings)
  24 siblings, 2 replies; 68+ messages in thread
From: Alejandro Riveira Fernández @ 2007-12-11 23:43 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

El Wed, 12 Dec 2007 00:31:18 +0100
Rene Herman <rene.herman@gmail.com> escribió:

> Good day.
> 
> Would some people on x86 (both 32 and 64) be kind enough to compile and run 
> the attached program? This is about testing how long I/O port access to port 
> 0x80 takes. It measures in CPU cycles so CPU speed is crucial in reporting.
> 
> Posted a previous incarnation of this before, buried in the outb 0x80 thread 
> which had a serialising problem. This one should as far as I can see measure 
> the right thing though. Please yell if you disagree...
> 
> For me, on a Duron 1300 (AMD756 chipset) I have a constant:
> 
> rene@7ixe4:~/src/port80$ su -c ./port80
> cycles: out 2400, in 2400
> 
> and on a PII 400 (Intel 440BX chipset) a constant:
> 
> rene@6bap:~/src/port80$ su -c ./port80
> cycles: out 553, in 251
> 
> Results are (mostly) independent of compiler optimisation, but testing with 
> an -O2 compile should be most useful. Thanks!
> 
> Rene.

 On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get:

 cycles: out 1844674407370808, in 1844674407369087
 
It is not constant but variations are not significant afaics


^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:40 ` Maxim Levitsky
@ 2007-12-11 23:44   ` Rene Herman
  2007-12-12  0:14     ` Maxim Levitsky
  0 siblings, 1 reply; 68+ messages in thread
From: Rene Herman @ 2007-12-11 23:44 UTC (permalink / raw)
  To: Maxim Levitsky
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On 12-12-07 00:40, Maxim Levitsky wrote:

> maxim@MAIN:~/tmp$ sudo ./port800
> cycles: out 1767, in 1147
> maxim@MAIN:~/tmp$ sudo ./port800
> cycles: out 1774, in 1148
> maxim@MAIN:~/tmp$ sudo ./port800
> cycles: out 1769, in 1150
> maxim@MAIN:~/tmp$ sudo ./port800
> cycles: out 1769, in 1150
> maxim@MAIN:~/tmp$ sudo ./port800
> cycles: out 1777, in 1150
> maxim@MAIN:~/tmp$ sudo ./port800
> cycles: out 1766, in 1149
> maxim@MAIN:~/tmp$ sudo ./port800
> cycles: out 1768, in 1148
> maxim@MAIN:~/tmp$ sudo ./port800
> cycles: out 1765, in 1147
> 
> 
> Core 2 Duo system (ICH8/Intel DG965RY motherboard)

1.8 Ghz?

Rene.


^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:43 ` Alejandro Riveira Fernández
@ 2007-12-11 23:51   ` Rene Herman
  2007-12-12  0:09     ` Alejandro Riveira Fernández
       [not found]   ` <Pine.LNX.4.61.0712120753210.4443@chaos.analogic.com>
  1 sibling, 1 reply; 68+ messages in thread
From: Rene Herman @ 2007-12-11 23:51 UTC (permalink / raw)
  To: Alejandro Riveira Fernández
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On 12-12-07 00:43, Alejandro Riveira Fernández wrote:

>  On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get:
> 
>  cycles: out 1844674407370808, in 1844674407369087
>  
> It is not constant but variations are not significant afaics

Eh, oh, I guess you need to compile as a 32-bit binary...

Rene.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
  2007-12-11 23:40 ` Maxim Levitsky
  2007-12-11 23:43 ` Alejandro Riveira Fernández
@ 2007-12-11 23:55 ` Nigel Cunningham
  2007-12-12  0:01   ` Rene Herman
  2007-12-12  1:19 ` Alistair John Strachan
                   ` (21 subsequent siblings)
  24 siblings, 1 reply; 68+ messages in thread
From: Nigel Cunningham @ 2007-12-11 23:55 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

Rene Herman wrote:
> Good day.
> 
> Would some people on x86 (both 32 and 64) be kind enough to compile and
> run the attached program? This is about testing how long I/O port access
> to port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in
> reporting.
> 
> Posted a previous incarnation of this before, buried in the outb 0x80
> thread which had a serialising problem. This one should as far as I can
> see measure the right thing though. Please yell if you disagree...
> 
> For me, on a Duron 1300 (AMD756 chipset) I have a constant:
> 
> rene@7ixe4:~/src/port80$ su -c ./port80
> cycles: out 2400, in 2400
> 
> and on a PII 400 (Intel 440BX chipset) a constant:
> 
> rene@6bap:~/src/port80$ su -c ./port80
> cycles: out 553, in 251
> 
> Results are (mostly) independent of compiler optimisation, but testing
> with an -O2 compile should be most useful. Thanks!

(AMD 1.8GHz Turion, running at 800MHz. ATI RS480 - Mitac 8350 mobo)

nigel@home:~/Downloads$ gcc port80.c -o port80
nigel@home:~/Downloads$ sudo ./port80
cycles: out 1235, in 1207
nigel@home:~/Downloads$ sudo ./port80
cycles: out 1238, in 1205
nigel@home:~/Downloads$ sudo ./port80
cycles: out 1237, in 1209
nigel@home:~/Downloads$ gcc -O2 port80.c -o port80
nigel@home:~/Downloads$ sudo ./port80
cycles: out 1844674407370794, in 1844674407369408
nigel@home:~/Downloads$ sudo ./port80
cycles: out 1844674407370795, in 1844674407369404
nigel@home:~/Downloads$ sudo ./port80
cycles: out 1844674407370795, in 1844674407369409
nigel@home:~/Downloads$ sudo ./port80
cycles: out 1844674407370798, in 1844674407369407
nigel@home:~/Downloads$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 36
model name      : AMD Turion(tm) 64 Mobile Technology ML-34
stepping        : 2
cpu MHz         : 800.000
cache size      : 1024 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt
lm 3dnowext 3dnow rep_good pni lahf_lm
bogomips        : 1592.87
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc


Regards,

Nigel

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:55 ` Nigel Cunningham
@ 2007-12-12  0:01   ` Rene Herman
  2007-12-12  2:07     ` Nigel Cunningham
  0 siblings, 1 reply; 68+ messages in thread
From: Rene Herman @ 2007-12-12  0:01 UTC (permalink / raw)
  To: nigel
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On 12-12-07 00:55, Nigel Cunningham wrote:

> (AMD 1.8GHz Turion, running at 800MHz. ATI RS480 - Mitac 8350 mobo)
> 
> nigel@home:~/Downloads$ gcc port80.c -o port80
> nigel@home:~/Downloads$ sudo ./port80
> cycles: out 1235, in 1207

Looking good.

> nigel@home:~/Downloads$ gcc -O2 port80.c -o port80
> nigel@home:~/Downloads$ sudo ./port80
> cycles: out 1844674407370794, in 1844674407369408

Obviously not. I suppose this changes with -m32 on the GCC command line? 
(sorry for missing that, I have no 64-bit machines).

Rene.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:51   ` Rene Herman
@ 2007-12-12  0:09     ` Alejandro Riveira Fernández
  2007-12-12  0:16       ` Rene Herman
  0 siblings, 1 reply; 68+ messages in thread
From: Alejandro Riveira Fernández @ 2007-12-12  0:09 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

El Wed, 12 Dec 2007 00:51:25 +0100
Rene Herman <rene.herman@gmail.com> escribió:

> On 12-12-07 00:43, Alejandro Riveira Fernández wrote:
> 
> >  On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get:
> > 
> >  cycles: out 1844674407370808, in 1844674407369087
> >  
> > It is not constant but variations are not significant afaics
> 
> Eh, oh, I guess you need to compile as a 32-bit binary...
 
 I tried without -O2 as Nigel Cunningham...

 cycles: out 1562, in 865
 cycles: out 1562, in 866
 cycles: out 1555, in 858
 cycles: out 1562, in 866
 
 With -m32 -O2
 cycles: out 1566, in 876
 cycles: out 1555, in 865
 cycles: out 1594, in 931
 cycles: out 1559, in 874
 ...
> 
> Rene.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:44   ` Rene Herman
@ 2007-12-12  0:14     ` Maxim Levitsky
  2007-12-12  0:27       ` Rene Herman
  0 siblings, 1 reply; 68+ messages in thread
From: Maxim Levitsky @ 2007-12-12  0:14 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On Wednesday 12 December 2007 01:44:42 Rene Herman wrote:
> On 12-12-07 00:40, Maxim Levitsky wrote:
> 
> > maxim@MAIN:~/tmp$ sudo ./port800
> > cycles: out 1767, in 1147
> > maxim@MAIN:~/tmp$ sudo ./port800
> > cycles: out 1774, in 1148
> > maxim@MAIN:~/tmp$ sudo ./port800
> > cycles: out 1769, in 1150
> > maxim@MAIN:~/tmp$ sudo ./port800
> > cycles: out 1769, in 1150
> > maxim@MAIN:~/tmp$ sudo ./port800
> > cycles: out 1777, in 1150
> > maxim@MAIN:~/tmp$ sudo ./port800
> > cycles: out 1766, in 1149
> > maxim@MAIN:~/tmp$ sudo ./port800
> > cycles: out 1768, in 1148
> > maxim@MAIN:~/tmp$ sudo ./port800
> > cycles: out 1765, in 1147
> > 
> > 
> > Core 2 Duo system (ICH8/Intel DG965RY motherboard)
> 
> 1.8 Ghz?
> 
> Rene.
> 
> 

2.1 GHZ. but usually reduced by EIST to 1.5 GHz
(It can have just two values above)

I did the tests again:


CPU frequency locked to 2128.000 Mhz:
maxim@MAIN:~/tmp$ sudo ./port800
cycles: out 1650, in 1065
maxim@MAIN:~/tmp$ sudo ./port800
cycles: out 1648, in 1066
maxim@MAIN:~/tmp$ sudo ./port800
cycles: out 1649, in 1065
maxim@MAIN:~/tmp$ sudo ./port800
cycles: out 1648, in 1065
maxim@MAIN:~/tmp$


CPU frequency locked to: 1596.000 Mhz
maxim@MAIN:~/tmp$ sudo ./port800
cycles: out 1730, in 1138
maxim@MAIN:~/tmp$ sudo ./port800
cycles: out 1730, in 1138
maxim@MAIN:~/tmp$ sudo ./port800
cycles: out 1735, in 1140
maxim@MAIN:~/tmp$ sudo ./port800
cycles: out 1734, in 1139
maxim@MAIN:~/tmp$ sudo ./port800
cycles: out 1734, in 1138
maxim@MAIN:~/tmp$ 2128.000    


A bit strange, isn't it?
Regards,
	Maxim Levitsky

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12  0:09     ` Alejandro Riveira Fernández
@ 2007-12-12  0:16       ` Rene Herman
  2007-12-12 11:43         ` Alejandro Riveira Fernández
  2007-12-12 21:02         ` H. Peter Anvin
  0 siblings, 2 replies; 68+ messages in thread
From: Rene Herman @ 2007-12-12  0:16 UTC (permalink / raw)
  To: Alejandro Riveira Fernández
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On 12-12-07 01:09, Alejandro Riveira Fernández wrote:

>>>  On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get:
>>>
>>>  cycles: out 1844674407370808, in 1844674407369087
>>>  
>>> It is not constant but variations are not significant afaics
>> Eh, oh, I guess you need to compile as a 32-bit binary...
>  
>  I tried without -O2 as Nigel Cunningham...
> 
>  cycles: out 1562, in 865
>  cycles: out 1562, in 866
>  cycles: out 1555, in 858
>  cycles: out 1562, in 866
>  
>  With -m32 -O2
>  cycles: out 1566, in 876
>  cycles: out 1555, in 865
>  cycles: out 1594, in 931
>  cycles: out 1559, in 874

Great, thanks much for reporting. Sort of interesting in itself that without 
-O2 you do still get correct results on 64-bit but for some other time.

You're the first one to go significantly below 1 us it seems.

Rene.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12  0:14     ` Maxim Levitsky
@ 2007-12-12  0:27       ` Rene Herman
  0 siblings, 0 replies; 68+ messages in thread
From: Rene Herman @ 2007-12-12  0:27 UTC (permalink / raw)
  To: Maxim Levitsky
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On 12-12-07 01:14, Maxim Levitsky wrote:

> CPU frequency locked to 2128.000 Mhz:
> maxim@MAIN:~/tmp$ sudo ./port800
> cycles: out 1650, in 1065

> CPU frequency locked to: 1596.000 Mhz
> maxim@MAIN:~/tmp$ sudo ./port800
> cycles: out 1730, in 1138

> A bit strange, isn't it?

Well, yes. Don't know what that effect is. A bus-clock divided from the CPU 
clock comes to mind, but I believe that shouldn't happen to LPC.

Anyways, we're looking for an upper bound and that's still nicely below 2 us 
on everything upto now, so I guess it doesn't matter all that much. Thanks!

Rene.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (2 preceding siblings ...)
  2007-12-11 23:55 ` Nigel Cunningham
@ 2007-12-12  1:19 ` Alistair John Strachan
  2007-12-12  1:28 ` Randy Dunlap
                   ` (20 subsequent siblings)
  24 siblings, 0 replies; 68+ messages in thread
From: Alistair John Strachan @ 2007-12-12  1:19 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On Tuesday 11 December 2007 23:31:18 Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to
> port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in
> reporting.

cycles: out 2712, in 2606

1.5GHz C7, Via chipset. 32bit OS.

-- 
Cheers,
Alistair.

137/1 Warrender Park Road, Edinburgh, UK.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (3 preceding siblings ...)
  2007-12-12  1:19 ` Alistair John Strachan
@ 2007-12-12  1:28 ` Randy Dunlap
  2007-12-12  1:40 ` Mike Lampard
                   ` (19 subsequent siblings)
  24 siblings, 0 replies; 68+ messages in thread
From: Randy Dunlap @ 2007-12-12  1:28 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On Wed, 12 Dec 2007 00:31:18 +0100 Rene Herman wrote:

> Good day.
> 
> Would some people on x86 (both 32 and 64) be kind enough to compile and run 
> the attached program? This is about testing how long I/O port access to port 
> 0x80 takes. It measures in CPU cycles so CPU speed is crucial in reporting.
> 
> Posted a previous incarnation of this before, buried in the outb 0x80 thread 
> which had a serialising problem. This one should as far as I can see measure 
> the right thing though. Please yell if you disagree...
> 
> For me, on a Duron 1300 (AMD756 chipset) I have a constant:
> 
> rene@7ixe4:~/src/port80$ su -c ./port80
> cycles: out 2400, in 2400
> 
> and on a PII 400 (Intel 440BX chipset) a constant:
> 
> rene@6bap:~/src/port80$ su -c ./port80
> cycles: out 553, in 251
> 
> Results are (mostly) independent of compiler optimisation, but testing with 
> an -O2 compile should be most useful. Thanks!

(-m32 build on x86_64)

midway:/home/rddunlap/src # ./port80
cycles: out 2702, in 1903
midway:/home/rddunlap/src # ./port80
cycles: out 2688, in 1893
midway:/home/rddunlap/src # ./port80
cycles: out 2703, in 1909
midway:/home/rddunlap/src # ./port80
cycles: out 2687, in 1893
midway:/home/rddunlap/src # ./port80
cycles: out 2687, in 1893
midway:/home/rddunlap/src # ./port80
cycles: out 2701, in 1907
midway:/home/rddunlap/src # ./port80
cycles: out 2701, in 1919
midway:/home/rddunlap/src # ./port80
cycles: out 2687, in 1893
midway:/home/rddunlap/src # ./port80
cycles: out 2701, in 1909
midway:/home/rddunlap/src # ./port80
cycles: out 2706, in 1906

/proc/cpuinfo says CPU speed is
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      :               Intel(R) Pentium(R) D CPU 3.00GHz
stepping        : 4
cpu MHz         : 2999.988


---
~Randy

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (4 preceding siblings ...)
  2007-12-12  1:28 ` Randy Dunlap
@ 2007-12-12  1:40 ` Mike Lampard
  2007-12-12  5:23 ` Kyle McMartin
                   ` (18 subsequent siblings)
  24 siblings, 0 replies; 68+ messages in thread
From: Mike Lampard @ 2007-12-12  1:40 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On Wed, 12 Dec 2007 10:01:18 am Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to
> port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in
> reporting.
>
> Posted a previous incarnation of this before, buried in the outb 0x80
> thread which had a serialising problem. This one should as far as I can see
> measure the right thing though. Please yell if you disagree...

cycles: out 1399, in 303
cycles: out 1347, in 297
cycles: out 1235, in 251
cycles: out 1342, in 249
cycles: out 1393, in 274
cycles: out 1241, in 261
cycles: out 1238, in 251
cycles: out 1383, in 277
cycles: out 1228, in 252
cycles: out 1413, in 303
cycles: out 1394, in 268
cycles: out 1378, in 292
cycles: out 1239, in 265

 -m32 build on x64
processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 107
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
stepping        : 1
cpu MHz         : 2300.000

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12  0:01   ` Rene Herman
@ 2007-12-12  2:07     ` Nigel Cunningham
  0 siblings, 0 replies; 68+ messages in thread
From: Nigel Cunningham @ 2007-12-12  2:07 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

Rene Herman wrote:
> On 12-12-07 00:55, Nigel Cunningham wrote:
> 
>> (AMD 1.8GHz Turion, running at 800MHz. ATI RS480 - Mitac 8350 mobo)
>>
>> nigel@home:~/Downloads$ gcc port80.c -o port80
>> nigel@home:~/Downloads$ sudo ./port80
>> cycles: out 1235, in 1207
> 
> Looking good.
> 
>> nigel@home:~/Downloads$ gcc -O2 port80.c -o port80
>> nigel@home:~/Downloads$ sudo ./port80
>> cycles: out 1844674407370794, in 1844674407369408
> 
> Obviously not. I suppose this changes with -m32 on the GCC command line?
> (sorry for missing that, I have no 64-bit machines).

Yes, it does:

nigel@home:~/Downloads$ gcc -m32 -o port80 port80.c
nigel@home:~/Downloads$ sudo ./port80
cycles: out 1231, in 1208
nigel@home:~/Downloads$ sudo ./port80
cycles: out 1233, in 1210

Incidentally:

nigel@home:~/Downloads$ processor_speed

(A little script I made because my lappy does a solid lock every now and
then that seems to be cpu-freq related - locking it to one frequency
makes the lock far less common).

Speed is now 1800000.
nigel@home:~/Downloads$ sudo ./port80
cycles: out 2472, in 2505
nigel@home:~/Downloads$ sudo ./port80
cycles: out 2489, in 2515
nigel@home:~/Downloads$ sudo ./port80
cycles: out 2481, in 2503
nigel@home:~/Downloads$ sudo ./port80
cycles: out 2476, in 2507

So the same effect Maxim reported is seen here.

Regards,

Nigel

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (5 preceding siblings ...)
  2007-12-12  1:40 ` Mike Lampard
@ 2007-12-12  5:23 ` Kyle McMartin
  2007-12-12  7:18   ` Rene Herman
  2007-12-12 19:25   ` H. Peter Anvin
  2007-12-12  8:17 ` Paolo Ornati
                   ` (17 subsequent siblings)
  24 siblings, 2 replies; 68+ messages in thread
From: Kyle McMartin @ 2007-12-12  5:23 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
> 	asm volatile ("rdtsc": "=A" (tsc));

rdtsc returns a 64-bit value in two 32-bit regs, you need to do

inline unsigned long long rdtsc(void)
{
	unsigned int lo, hi;
	asm volatile ("rdtsc": "=a" (lo), "=d" (hi));
	return (unsigned long long)hi << 32 | lo;
}

as in msr.h, otherwise you'll only be looking at the value in %rax.

cheers,
	Kyle

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12  5:23 ` Kyle McMartin
@ 2007-12-12  7:18   ` Rene Herman
  2007-12-13  2:41     ` H. Peter Anvin
  2007-12-12 19:25   ` H. Peter Anvin
  1 sibling, 1 reply; 68+ messages in thread
From: Rene Herman @ 2007-12-12  7:18 UTC (permalink / raw)
  To: Kyle McMartin
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On 12-12-07 06:23, Kyle McMartin wrote:

> On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
>> 	asm volatile ("rdtsc": "=A" (tsc));
> 
> rdtsc returns a 64-bit value in two 32-bit regs, you need to do
> 
> inline unsigned long long rdtsc(void)
> {
> 	unsigned int lo, hi;
> 	asm volatile ("rdtsc": "=a" (lo), "=d" (hi));
> 	return (unsigned long long)hi << 32 | lo;
> }
> 
> as in msr.h, otherwise you'll only be looking at the value in %rax.

On 32-bit, "=A" is edx:eax. Not sure what the point is in not letting it be 
that on 64-bit in fact, but yes, the thing should be compiled as 32-bit.

Rene.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (6 preceding siblings ...)
  2007-12-12  5:23 ` Kyle McMartin
@ 2007-12-12  8:17 ` Paolo Ornati
  2007-12-12  8:38   ` Edwin de Caluwé
  2007-12-12  8:35 ` Dave Young
                   ` (16 subsequent siblings)
  24 siblings, 1 reply; 68+ messages in thread
From: Paolo Ornati @ 2007-12-12  8:17 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On Wed, 12 Dec 2007 00:31:18 +0100
Rene Herman <rene.herman@gmail.com> wrote:
> 
> and on a PII 400 (Intel 440BX chipset) a constant:
> 
> rene@6bap:~/src/port80$ su -c ./port80
> cycles: out 553, in 251
> 
> Results are (mostly) independent of compiler optimisation, but testing with 
> an -O2 compile should be most useful. Thanks!
>

### Core2 Duo 1.8 GHz ###

X86_64 -m32 -O2:

$ for i in `seq 5`; do sudo ./port80; sleep 1; done
cycles: out 1498, in 964
cycles: out 1498, in 964
cycles: out 1499, in 964
cycles: out 1498, in 964
cycles: out 1498, in 965

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz
stepping	: 6
cpu MHz		: 1864.805
cache size	: 2048 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips	: 3731.82
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

[...]


-- 
	Paolo Ornati
	Linux 2.6.24-rc4-g94545bad on x86_64

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (7 preceding siblings ...)
  2007-12-12  8:17 ` Paolo Ornati
@ 2007-12-12  8:35 ` Dave Young
  2007-12-12  8:48 ` Jiri Slaby
                   ` (15 subsequent siblings)
  24 siblings, 0 replies; 68+ messages in thread
From: Dave Young @ 2007-12-12  8:35 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On Dec 12, 2007 7:31 AM, Rene Herman <rene.herman@gmail.com> wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to port
> 0x80 takes. It measures in CPU cycles so CPU speed is crucial in reporting.
>
> Posted a previous incarnation of this before, buried in the outb 0x80 thread
> which had a serialising problem. This one should as far as I can see measure
> the right thing though. Please yell if you disagree...
>
> For me, on a Duron 1300 (AMD756 chipset) I have a constant:
>
> rene@7ixe4:~/src/port80$ su -c ./port80
> cycles: out 2400, in 2400
>
> and on a PII 400 (Intel 440BX chipset) a constant:
>
> rene@6bap:~/src/port80$ su -c ./port80
> cycles: out 553, in 251
>
> Results are (mostly) independent of compiler optimisation, but testing with
> an -O2 compile should be most useful. Thanks!
>
> Rene.
>
> /* gcc -W -Wall -O2 -o port80 port80.c */
>
> #include <stdlib.h>
> #include <stdio.h>
>
> #include <sys/io.h>
>
> #define LOOPS 10000
>
> inline unsigned long long rdtsc(void)
> {
>         unsigned long long tsc;
>
>         asm volatile ("rdtsc": "=A" (tsc));
>
>         return tsc;
> }
>
> inline void serialize(void)
> {
>         asm volatile ("cpuid": : : "eax", "ebx", "ecx", "edx");
> }
>
> int main(void)
> {
>         unsigned long long start;
>         unsigned long long overhead;
>         unsigned long long output;
>         unsigned long long input;
>         int i;
>
>         if (iopl(3) < 0) {
>                 perror("iopl");
>                 return EXIT_FAILURE;
>         }
>
>         asm volatile ("cli");
>         start = rdtsc();
>         for (i = 0; i < LOOPS; i++) {
>                 serialize();
>                 serialize();
>         }
>         overhead = rdtsc() - start;
>
>         start = rdtsc() + overhead;
>         for (i = 0; i < LOOPS; i++) {
>                 serialize();
>                 asm volatile ("outb %al, $0x80");
>                 serialize();
>         }
>         output = rdtsc() - start;
>
>         start = rdtsc() + overhead;
>         for (i = 0; i < LOOPS; i++) {
>                 serialize();
>                 asm volatile ("inb $0x80, %%al": : : "al");
>                 serialize();
>         }
>         input = rdtsc() - start;
>         asm volatile ("sti");
>
>         output /= LOOPS;
>         input  /= LOOPS;
>         printf("cycles: out %llu, in %llu\n", output, input);
>
>         return EXIT_SUCCESS;
> }
>
>

dave@darkstar:~/work/tmp$ sudo ./port80
cycles: out 2522, in 1788
dave@darkstar:~/work/tmp$ sudo ./port80
cycles: out 2522, in 1795
dave@darkstar:~/work/tmp$ sudo ./port80
cycles: out 2523, in 1788
dave@darkstar:~/work/tmp$ sudo ./port80
cycles: out 2516, in 1788
dave@darkstar:~/work/tmp$ sudo ./port80
cycles: out 2516, in 1798
dave@darkstar:~/work/tmp$ sudo ./port80
cycles: out 2523, in 1788
dave@darkstar:~/work/tmp$ sudo ./port80
cycles: out 2518, in 1788
dave@darkstar:~/work/tmp$ sudo ./port80
cycles: out 2517, in 1788
dave@darkstar:~/work/tmp$ sudo ./port80
cycles: out 2523, in 1788
dave@darkstar:~/work/tmp$ sudo ./port80
cycles: out 2517, in 1788

dave@darkstar:~$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      : Intel(R) Pentium(R) D CPU 2.80GHz
stepping        : 7
cpu MHz         : 2793.194
cache size      : 1024 KB

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12  8:17 ` Paolo Ornati
@ 2007-12-12  8:38   ` Edwin de Caluwé
  0 siblings, 0 replies; 68+ messages in thread
From: Edwin de Caluwé @ 2007-12-12  8:38 UTC (permalink / raw)
  To: Paolo Ornati
  Cc: Rene Herman, Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

Exactly constant timing in every iteration:

cycles: out 667, in 305

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Celeron (Coppermine)
stepping        : 3
cpu MHz         : 497.582
cache size      : 128 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr sse up
bogomips        : 996.21
clflush size    : 32


On 12/12/07, Paolo Ornati <ornati@fastwebnet.it> wrote:
> On Wed, 12 Dec 2007 00:31:18 +0100
> Rene Herman <rene.herman@gmail.com> wrote:
> >
> > and on a PII 400 (Intel 440BX chipset) a constant:
> >
> > rene@6bap:~/src/port80$ su -c ./port80
> > cycles: out 553, in 251
> >
> > Results are (mostly) independent of compiler optimisation, but testing
> with
> > an -O2 compile should be most useful. Thanks!
> >
>
> ### Core2 Duo 1.8 GHz ###
>
> X86_64 -m32 -O2:
>
> $ for i in `seq 5`; do sudo ./port80; sleep 1; done
> cycles: out 1498, in 964
> cycles: out 1498, in 964
> cycles: out 1499, in 964
> cycles: out 1498, in 964
> cycles: out 1498, in 965
>
> processor	: 0
> vendor_id	: GenuineIntel
> cpu family	: 6
> model		: 15
> model name	: Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz
> stepping	: 6
> cpu MHz		: 1864.805
> cache size	: 2048 KB
> physical id	: 0
> siblings	: 2
> core id		: 0
> cpu cores	: 2
> fpu		: yes
> fpu_exception	: yes
> cpuid level	: 10
> wp		: yes
> flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
> pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
> constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2
> ssse3 cx16 xtpr lahf_lm
> bogomips	: 3731.82
> clflush size	: 64
> cache_alignment	: 64
> address sizes	: 36 bits physical, 48 bits virtual
> power management:
>
> [...]
>
>
> --
> 	Paolo Ornati
> 	Linux 2.6.24-rc4-g94545bad on x86_64
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (8 preceding siblings ...)
  2007-12-12  8:35 ` Dave Young
@ 2007-12-12  8:48 ` Jiri Slaby
  2007-12-12 11:25   ` Jiri Slaby
  2007-12-12  8:59 ` Juergen Beisert
                   ` (14 subsequent siblings)
  24 siblings, 1 reply; 68+ messages in thread
From: Jiri Slaby @ 2007-12-12  8:48 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On 12/12/2007 12:31 AM, Rene Herman wrote:
> Good day.
> 
> Would some people on x86 (both 32 and 64) be kind enough to compile and
> run the attached program? This is about testing how long I/O port access

model name      : Intel(R) Core(TM)2 Duo CPU     E6850  @ 3.00GHz

cycles: out 6490, in 3135
cycles: out 6484, in 3126
cycles: out 6511, in 3128
cycles: out 6500, in 3135
cycles: out 6492, in 3154
cycles: out 6506, in 3136
cycles: out 6516, in 3144
cycles: out 6489, in 3140
cycles: out 6492, in 3129
cycles: out 6507, in 3130


^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (9 preceding siblings ...)
  2007-12-12  8:48 ` Jiri Slaby
@ 2007-12-12  8:59 ` Juergen Beisert
  2007-12-12 14:30   ` Rene Herman
  2007-12-12  9:55 ` Luciano Rocha
                   ` (13 subsequent siblings)
  24 siblings, 1 reply; 68+ messages in thread
From: Juergen Beisert @ 2007-12-12  8:59 UTC (permalink / raw)
  To: linux-kernel

$ for i in `seq 5`; do ./port80; sleep 1; done
cycles: out 5260, in 2372
cycles: out 5260, in 2384
cycles: out 5260, in 2323
cycles: out 5270, in 2382
cycles: out 5259, in 2323

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 7
model name      : Pentium III (Katmai)
stepping        : 3
cpu MHz         : 501.208
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 mmx fxsr sse
bogomips        : 993.28

#########

$ for i in `seq 5`; do ./port80; sleep 1; done
cycles: out 1214, in 1095
cycles: out 1215, in 1094
cycles: out 1214, in 1095
cycles: out 1216, in 1095
cycles: out 1213, in 1093

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 11
model name      : Intel(R) Celeron(TM) CPU                1000MHz
stepping        : 1
cpu MHz         : 1002.285
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat 
pse36 mmx fxsr sse
bogomips        : 1998.84

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (10 preceding siblings ...)
  2007-12-12  8:59 ` Juergen Beisert
@ 2007-12-12  9:55 ` Luciano Rocha
  2007-12-12  9:57 ` Romano Giannetti
                   ` (12 subsequent siblings)
  24 siblings, 0 replies; 68+ messages in thread
From: Luciano Rocha @ 2007-12-12  9:55 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

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

On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
>  Good day.
> 
>  Would some people on x86 (both 32 and 64) be kind enough to compile and run 
>  the attached program? This is about testing how long I/O port access to port 
>  0x80 takes. It measures in CPU cycles so CPU speed is crucial in reporting.
> 

$ sudo ./port80
cycles: out 2729, in 1872
$ sudo ./port80
cycles: out 2729, in 1872
$ sudo ./port80
cycles: out 2711, in 1856
$ sudo ./port80
cycles: out 2711, in 1856

model name      : Intel(R) Pentium(R) 4 CPU 1.90GHz
stepping        : 2
cpu MHz         : 1917.229
cache size      : 256 KB

-- 
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (11 preceding siblings ...)
  2007-12-12  9:55 ` Luciano Rocha
@ 2007-12-12  9:57 ` Romano Giannetti
  2007-12-12 16:27   ` Rene Herman
  2007-12-12 10:28 ` Peter Zijlstra
                   ` (11 subsequent siblings)
  24 siblings, 1 reply; 68+ messages in thread
From: Romano Giannetti @ 2007-12-12  9:57 UTC (permalink / raw)
  To: Rene Herman; +Cc: Linux Kernel



On Wed, 2007-12-12 at 00:31 +0100, Rene Herman wrote:
> cc -W -Wall -O2 -o port80 port80.c

On a laptop with a CoreDuo T2080/1.73GHz, but running on battery at 
800 MHz (on-demand):

(0)rukbat:~/tmp% for i in {1..10}; do
sudo ./port80
done
cycles: out 3575, in 2844
cycles: out 3589, in 2923
cycles: out 3672, in 2864
cycles: out 3575, in 2843
cycles: out 3607, in 2859
cycles: out 3623, in 2877
cycles: out 3604, in 2848
cycles: out 3575, in 2849
cycles: out 3598, in 2861
cycles: out 3613, in 2861

With a cpu-hog running, cpufreq reporting 1.73GHz:

 
(0)rukbat:~/tmp% for i in {1..10}; do
sudo ./port80
done
cycles: out 3446, in 2652
cycles: out 3499, in 2668
cycles: out 3395, in 2578
cycles: out 3452, in 2662
cycles: out 3448, in 2662
cycles: out 3622, in 2754
cycles: out 3457, in 2662
cycles: out 3451, in 2660
cycles: out 3581, in 2850
cycles: out 3477, in 2696

HTH,
	Romano 

Romano 

-- 
Sorry for the disclaimer --- ¡I cannot stop it!



--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. 

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (12 preceding siblings ...)
  2007-12-12  9:57 ` Romano Giannetti
@ 2007-12-12 10:28 ` Peter Zijlstra
  2007-12-12 10:34 ` Dave Haywood
                   ` (10 subsequent siblings)
  24 siblings, 0 replies; 68+ messages in thread
From: Peter Zijlstra @ 2007-12-12 10:28 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os


On Wed, 2007-12-12 at 00:31 +0100, Rene Herman wrote:
> Good day.
> 
> Would some people on x86 (both 32 and 64) be kind enough to compile and run 
> the attached program? This is about testing how long I/O port access to port 
> 0x80 takes. It measures in CPU cycles so CPU speed is crucial in reporting.
> 
> Posted a previous incarnation of this before, buried in the outb 0x80 thread 
> which had a serialising problem. This one should as far as I can see measure 
> the right thing though. Please yell if you disagree...
> 
> For me, on a Duron 1300 (AMD756 chipset) I have a constant:
> 
> rene@7ixe4:~/src/port80$ su -c ./port80
> cycles: out 2400, in 2400
> 
> and on a PII 400 (Intel 440BX chipset) a constant:
> 
> rene@6bap:~/src/port80$ su -c ./port80
> cycles: out 553, in 251
> 
> Results are (mostly) independent of compiler optimisation, but testing with 
> an -O2 compile should be most useful. Thanks!

Since a lot of people reported timings for all the fancy new x86_64
hardware, I've not included those. Timings for my ancient machines still
in service:

$ gcc -o port80 -O2 port80.c
$ sudo ./port80
cycles: out 1736, in 1735
$ sudo ./port80
cycles: out 1831, in 1827
$ sudo ./port80
cycles: out 1735, in 1735
$ sudo ./port80
cycles: out 1743, in 1737
$ sudo ./port80
cycles: out 1737, in 1734

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 6
model name      : AMD Athlon(tm) MP 1800+
stepping        : 2
cpu MHz         : 1533.420
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov
pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow ts
bogomips        : 3069.09
clflush size    : 32

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 6
model name      : AMD Athlon(tm) Processor
stepping        : 2
cpu MHz         : 1533.420
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov   pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow ts
bogomips        : 3067.07
clflush size    : 32


---

# ./port80
cycles: out 812, in 354
# ./port80
cycles: out 811, in 354
# ./port80
cycles: out 811, in 354
# ./port80
cycles: out 811, in 354

# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 1
cpu MHz         : 672.071
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse
bogomips        : 1331.20


---


# ./port80
cycles: out 116, in 47
# ./port80
cycles: out 116, in 47
# ./port80
cycles: out 116, in 47
# ./port80
cycles: out 116, in 47

# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 5
model           : 2
model name      : Pentium 75 - 200
stepping        : 12
cpu MHz         : 99.476
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : yes
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8
bogomips        : 198.24


P133 clocked at 100MHz


^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (13 preceding siblings ...)
  2007-12-12 10:28 ` Peter Zijlstra
@ 2007-12-12 10:34 ` Dave Haywood
  2007-12-12 11:57 ` Ville Syrjälä
                   ` (9 subsequent siblings)
  24 siblings, 0 replies; 68+ messages in thread
From: Dave Haywood @ 2007-12-12 10:34 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile
> and run the attached program? This is about testing how long I/O port
> access to port 0x80 takes. It measures in CPU cycles so CPU speed is
> crucial in reporting.

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 6
cpu MHz         : 930.347
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips        : 1861.99
clflush size    : 32

cycles: out 1183, in 706

cycles: out 1183, in 707

cycles: out 1182, in 706

cycles: out 1182, in 706

cycles: out 1183, in 706

cycles: out 1182, in 706

cycles: out 1182, in 706

cycles: out 1183, in 706

cycles: out 1183, in 707

cycles: out 1183, in 707

cycles: out 1183, in 706

cycles: out 1183, in 706

cycles: out 1183, in 706

cycles: out 1182, in 706

cycles: out 1183, in 707

cycles: out 1183, in 707

cycles: out 1183, in 706

cycles: out 1183, in 706

cycles: out 1182, in 706

cycles: out 1183, in 706

cycles: out 1183, in 706

cycles: out 1183, in 706

Dave.



^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12  8:48 ` Jiri Slaby
@ 2007-12-12 11:25   ` Jiri Slaby
  2007-12-12 15:50     ` Rene Herman
                       ` (2 more replies)
  0 siblings, 3 replies; 68+ messages in thread
From: Jiri Slaby @ 2007-12-12 11:25 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On Dec 12, 2007 9:48 AM, Jiri Slaby <jirislaby@gmail.com> wrote:
> On 12/12/2007 12:31 AM, Rene Herman wrote:
> > Good day.
> >
> > Would some people on x86 (both 32 and 64) be kind enough to compile and
> > run the attached program? This is about testing how long I/O port access

model name      : Intel(R) Xeon(R) CPU           E5335  @ 2.00GHz

cycles: out 3217, in 1898
cycles: out 3217, in 1898
cycles: out 3217, in 1898
cycles: out 3217, in 1898
cycles: out 3217, in 1898
cycles: out 3217, in 1898
cycles: out 3217, in 1898
cycles: out 3217, in 1898
cycles: out 3217, in 1898
cycles: out 3217, in 1898

model name      : Dual Core AMD Opteron(tm) Processor 275
cycles: out 5508, in 5524
cycles: out 5509, in 5525
cycles: out 5510, in 5522
cycles: out 5512, in 5522
cycles: out 5512, in 5522
cycles: out 5510, in 5524
cycles: out 5510, in 5522
cycles: out 5511, in 5525
cycles: out 5513, in 5521
cycles: out 5509, in 5522

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12  0:16       ` Rene Herman
@ 2007-12-12 11:43         ` Alejandro Riveira Fernández
  2007-12-12 21:02         ` H. Peter Anvin
  1 sibling, 0 replies; 68+ messages in thread
From: Alejandro Riveira Fernández @ 2007-12-12 11:43 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

El Wed, 12 Dec 2007 01:16:06 +0100
Rene Herman <rene.herman@gmail.com> escribió:

> On 12-12-07 01:09, Alejandro Riveira Fernández wrote:

[...]

> 
> Great, thanks much for reporting. Sort of interesting in itself that without 
> -O2 you do still get correct results on 64-bit but for some other time.
> 
> You're the first one to go significantly below 1 us it seems.

 :( I have seen the other msg and i have to say that the tests where done at
1GHz not at full speed. At full speed i see
 
 cycles: out 3025, in 1653
 cycles: out 3040, in 1708
 cycles: out 3044, in 1650
 cycles: out 3034, in 1652
 cycles: out 3035, in 1652
 cycles: out 3037, in 1652
 cycles: out 3043, in 1709
 cycles: out 3032, in 1648
 cycles: out 3039, in 1652
 cycles: out 3041, in 1652
 cycles: out 3048, in 1704
 cycles: out 3040, in 1650
 cycles: out 3023, in 1631
 cycles: out 3036, in 1652
 cycles: out 3042, in 1706
 cycles: out 3047, in 1708
 cycles: out 3047, in 1711
 cycles: out 3036, in 1652


 

> 
> Rene.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (14 preceding siblings ...)
  2007-12-12 10:34 ` Dave Haywood
@ 2007-12-12 11:57 ` Ville Syrjälä
  2007-12-13 16:42   ` Ville Syrjälä
  2007-12-12 16:16 ` John Stoffel
                   ` (8 subsequent siblings)
  24 siblings, 1 reply; 68+ messages in thread
From: Ville Syrjälä @ 2007-12-12 11:57 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run 
> the attached program? This is about testing how long I/O port access to 
> port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in 
> reporting.

vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz
stepping        : 6

cpu MHz         : 2394.000
cycles: out 1830, in 1166

cpu MHz         : 1596.000
cycles: out 1925, in 1266

##

vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 10

cpu MHz         : 850.000
cycles: out 1142, in 475

cpu MHz         : 700.000
cycles: out 914, in 406

##

vendor_id       : AuthenticAMD
cpu family      : 6
model           : 7
model name      : AMD Duron(tm) processor
stepping        : 1

cpu MHz         : 1300.108
cycles: out 2562, in 2562

##

vendor_id       : GenuineIntel
cpu family      : 6
model           : 5
model name      : Pentium II (Deschutes)
stepping        : 2

cpu MHz         : 449.242
cycles: out 607, in 272

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
       [not found]   ` <Pine.LNX.4.61.0712120753210.4443@chaos.analogic.com>
@ 2007-12-12 13:20     ` Rene Herman
  2007-12-12 13:23       ` linux-os (Dick Johnson)
  0 siblings, 1 reply; 68+ messages in thread
From: Rene Herman @ 2007-12-12 13:20 UTC (permalink / raw)
  To: linux-os (Dick Johnson)
  Cc: Alejandro Riveira Fernández, Linux Kernel, dpreed, Alan Cox,
	pavel, andi, rol, Krzysztof Halasa, david, hpa, john

On 12-12-07 13:59, linux-os (Dick Johnson) wrote:

> On Tue, 11 Dec 2007, [utf-8] Alejandro Riveira Fern?ndez wrote:

>> On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get:
>>
>> cycles: out 1844674407370808, in 1844674407369087
>>
>> It is not constant but variations are not significant afaics
>>
> 
> It looks as though this hardware does not have a port 0x80
> and its access is trapped by the hardware with a long time-out!
> This may be the reason when the _p was called "harmful" on this
> platform!
> 
> I'm not sure the "rules" for port access allow for this kind of
> behavior. This design may be defective, needing to be brought
> to the attention of the vendor. A decent vendor would update
> a FPGA and provide code to burn a new BIOS.

I'm afraid it's just the test that is "defective" as 64-bit code. For some 
reason "=A" doesn't mean edx:eax on amd64 even though it's a useful register 
pair to be able to name there as well. Didn't catch that being without amd64 
machines myself.

Oh well. gcc -m32 fixes it...

Rene.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12 13:20     ` Rene Herman
@ 2007-12-12 13:23       ` linux-os (Dick Johnson)
  0 siblings, 0 replies; 68+ messages in thread
From: linux-os (Dick Johnson) @ 2007-12-12 13:23 UTC (permalink / raw)
  To: Rene Herman
  Cc: Alejandro Riveira Fernández, Linux Kernel, dpreed, Alan Cox,
	pavel, andi, rol, Krzysztof Halasa, david, hpa, john


On Wed, 12 Dec 2007, Rene Herman wrote:

> On 12-12-07 13:59, linux-os (Dick Johnson) wrote:
>
>> On Tue, 11 Dec 2007, [utf-8] Alejandro Riveira Fern?ndez wrote:
>
>>> On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get:
>>>
>>> cycles: out 1844674407370808, in 1844674407369087
>>>
>>> It is not constant but variations are not significant afaics
>>>
>>
>> It looks as though this hardware does not have a port 0x80
>> and its access is trapped by the hardware with a long time-out!
>> This may be the reason when the _p was called "harmful" on this
>> platform!
>>
>> I'm not sure the "rules" for port access allow for this kind of
>> behavior. This design may be defective, needing to be brought
>> to the attention of the vendor. A decent vendor would update
>> a FPGA and provide code to burn a new BIOS.
>
> I'm afraid it's just the test that is "defective" as 64-bit code. For some
> reason "=A" doesn't mean edx:eax on amd64 even though it's a useful register
> pair to be able to name there as well. Didn't catch that being without amd64
> machines myself.
>
> Oh well. gcc -m32 fixes it...
>
> Rene.
>

Yep. By bad. I actually believed the returned value!


Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 BogoMips).
My book : http://www.AbominableFirebug.com/
_


****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12  8:59 ` Juergen Beisert
@ 2007-12-12 14:30   ` Rene Herman
  2007-12-12 15:12     ` Juergen Beisert
  0 siblings, 1 reply; 68+ messages in thread
From: Rene Herman @ 2007-12-12 14:30 UTC (permalink / raw)
  To: Juergen Beisert; +Cc: linux-kernel

On 12-12-07 09:59, Juergen Beisert wrote:

> $ for i in `seq 5`; do ./port80; sleep 1; done
> cycles: out 5260, in 2372
> cycles: out 5260, in 2384
> cycles: out 5260, in 2323
> cycles: out 5270, in 2382
> cycles: out 5259, in 2323
> 
> $ cat /proc/cpuinfo
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 7
> model name      : Pentium III (Katmai)
> stepping        : 3
> cpu MHz         : 501.208

This one's really wrong. This would be 10 microsecs. I suppose the 
machine/bus was heavily loaded or something?

> $ for i in `seq 5`; do ./port80; sleep 1; done
> cycles: out 1214, in 1095
> cycles: out 1215, in 1094
> cycles: out 1214, in 1095
> cycles: out 1216, in 1095
> cycles: out 1213, in 1093
> 
> $ cat /proc/cpuinfo
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 11
> model name      : Intel(R) Celeron(TM) CPU                1000MHz

This one's normal again...

Rene.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12 14:30   ` Rene Herman
@ 2007-12-12 15:12     ` Juergen Beisert
  0 siblings, 0 replies; 68+ messages in thread
From: Juergen Beisert @ 2007-12-12 15:12 UTC (permalink / raw)
  To: Rene Herman; +Cc: linux-kernel

On Wednesday 12 December 2007 15:30, Rene Herman wrote:
> On 12-12-07 09:59, Juergen Beisert wrote:
> > $ for i in `seq 5`; do ./port80; sleep 1; done
> > cycles: out 5260, in 2372
> > cycles: out 5260, in 2384
> > cycles: out 5260, in 2323
> > cycles: out 5270, in 2382
> > cycles: out 5259, in 2323
> >
> > $ cat /proc/cpuinfo
> > processor       : 0
> > vendor_id       : GenuineIntel
> > cpu family      : 6
> > model           : 7
> > model name      : Pentium III (Katmai)
> > stepping        : 3
> > cpu MHz         : 501.208
>
> This one's really wrong. This would be 10 microsecs. I suppose the
> machine/bus was heavily loaded or something?

Ups, your are right:

$ cat /proc/acpi/processor/CPU0/throttling
state count:             2
active state:            T1
states:
    T0:                  00%
   *T1:                  50%

With T0 it get:

$ for i in `seq 5`; do ./port80; sleep 1; done
cycles: out 684, in 280
cycles: out 684, in 280
cycles: out 684, in 280
cycles: out 684, in 280
cycles: out 684, in 280

Juergen

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12 11:25   ` Jiri Slaby
@ 2007-12-12 15:50     ` Rene Herman
  2007-12-12 15:53     ` Rene Herman
  2007-12-12 18:44     ` H. Peter Anvin
  2 siblings, 0 replies; 68+ messages in thread
From: Rene Herman @ 2007-12-12 15:50 UTC (permalink / raw)
  To: Jiri Slaby; +Cc: Linux Kernel

On 12-12-07 12:25, Jiri Slaby wrote:

Thanks for reporting! You have two results that are somewhat off:

> Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz
> cycles: out 6500, in 3135

6500 / 3000 = 2.17. Fairly high...

> Intel(R) Xeon(R) CPU E5335 @ 2.00GHz
> cycles: out 3217, in 1898

3217 / 2000 = 1.61. Okay.

> Dual Core AMD Opteron(tm) Processor 275
> cycles: out 5508, in 5524

2200 MHz right?

5508 / 2200 = 2.50. Very high.

Nothing was dozing off in some ACPI sleep state or something?

Rene.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12 11:25   ` Jiri Slaby
  2007-12-12 15:50     ` Rene Herman
@ 2007-12-12 15:53     ` Rene Herman
  2007-12-12 18:44     ` H. Peter Anvin
  2 siblings, 0 replies; 68+ messages in thread
From: Rene Herman @ 2007-12-12 15:53 UTC (permalink / raw)
  To: Jiri Slaby; +Cc: Linux Kernel

On 12-12-07 12:25, Jiri Slaby wrote:

Thanks for reporting! You have two results that are somewhat off:

> Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz
> cycles: out 6500, in 3135

6500 / 3000 = 2.17. Fairly high...

> Intel(R) Xeon(R) CPU E5335 @ 2.00GHz
> cycles: out 3217, in 1898

3217 / 2000 = 1.61. Okay.

> Dual Core AMD Opteron(tm) Processor 275
> cycles: out 5508, in 5524

2200 MHz right?

5508 / 2200 = 2.50. Very high.

Nothing was dozing off in some ACPI sleep state or something?

Rene.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (15 preceding siblings ...)
  2007-12-12 11:57 ` Ville Syrjälä
@ 2007-12-12 16:16 ` John Stoffel
  2007-12-12 16:39 ` Olivér Pintér
                   ` (7 subsequent siblings)
  24 siblings, 0 replies; 68+ messages in thread
From: John Stoffel @ 2007-12-12 16:16 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os


My results, PIII, Dual 550Mhz Xeon.

jfsnew:~/src> sudo ./port80
cycles: out 774, in 332
jfsnew:~/src> sudo ./port80
cycles: out 774, in 332
jfsnew:~/src> sudo ./port80
cycles: out 774, in 332
jfsnew:~/src> sudo ./port80
cycles: out 774, in 332
jfsnew:~/src> sudo ./port80
cycles: out 774, in 332
jfsnew:~/src> sudo ./port80
cycles: out 774, in 332
jfsnew:~/src> sudo ./port80
cycles: out 774, in 332
jfsnew:~/src> sudo ./port80
cycles: out 775, in 332
jfsnew:~/src> sudo ./port80
cycles: out 774, in 332
jfsnew:~/src> sudo ./port80
cycles: out 774, in 332
jfsnew:~/src> sudo ./port80
cycles: out 774, in 332
jfsnew:~/src> sudo ./port80
cycles: out 775, in 335


jfsnew:~/src> cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 7
model name      : Pentium III (Katmai)
stepping        : 3
cpu MHz         : 547.216
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse
bogomips        : 1095.01
clflush size    : 32

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12  9:57 ` Romano Giannetti
@ 2007-12-12 16:27   ` Rene Herman
  0 siblings, 0 replies; 68+ messages in thread
From: Rene Herman @ 2007-12-12 16:27 UTC (permalink / raw)
  To: Romano Giannetti; +Cc: Linux Kernel

On 12-12-07 10:57, Romano Giannetti wrote:

> On a laptop with a CoreDuo T2080/1.73GHz, but running on battery at 
> 800 MHz (on-demand):

> cycles: out 3575, in 2844

Okay, I'm going to ignore this one. This would be 4 microsecs but there are 
sleep states involved, and if a piece of hardware would work only when the 
system went to sleep I'd call it broken...

> With a cpu-hog running, cpufreq reporting 1.73GHz:

> cycles: out 3446, in 2652

So this one will do I guess. The test program disables interrupts and as 
such, the cpu-hog shouldn't have interfered with the measurement. Thanks!

Rene.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (16 preceding siblings ...)
  2007-12-12 16:16 ` John Stoffel
@ 2007-12-12 16:39 ` Olivér Pintér
  2007-12-12 16:53 ` Ondrej Zary
                   ` (6 subsequent siblings)
  24 siblings, 0 replies; 68+ messages in thread
From: Olivér Pintér @ 2007-12-12 16:39 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

pancs:/tmp# for((i=0;i<20;i++)); do ./port80; done
cycles: out 4098, in 2532
cycles: out 3951, in 2389
cycles: out 4043, in 2485
cycles: out 4058, in 2393
cycles: out 4056, in 2509
cycles: out 4063, in 2394
cycles: out 4076, in 2508
cycles: out 4143, in 2395
cycles: out 4062, in 2502
cycles: out 4084, in 2383
cycles: out 4055, in 2510
cycles: out 4228, in 2410
cycles: out 4071, in 2508
cycles: out 4062, in 2502
cycles: out 3982, in 2398
cycles: out 4103, in 2391
cycles: out 4160, in 2404
cycles: out 4010, in 2462
cycles: out 4105, in 2449
cycles: out 4028, in 2477

---------

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 15
model		: 2
model name	: Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping	: 9
cpu MHz		: 3150.045
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 2
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips	: 6303.37
clflush size	: 64

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 15
model		: 2
model name	: Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping	: 9
cpu MHz		: 3150.045
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 2
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips	: 6300.14
clflush size	: 64

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (17 preceding siblings ...)
  2007-12-12 16:39 ` Olivér Pintér
@ 2007-12-12 16:53 ` Ondrej Zary
  2007-12-12 17:00   ` H. Peter Anvin
  2007-12-12 16:59 ` Cyrill Gorcunov
                   ` (5 subsequent siblings)
  24 siblings, 1 reply; 68+ messages in thread
From: Ondrej Zary @ 2007-12-12 16:53 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On Wednesday 12 December 2007 00:31:18 Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to
> port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in
> reporting.
>
> Posted a previous incarnation of this before, buried in the outb 0x80
> thread which had a serialising problem. This one should as far as I can see
> measure the right thing though. Please yell if you disagree...
>
> For me, on a Duron 1300 (AMD756 chipset) I have a constant:
>
> rene@7ixe4:~/src/port80$ su -c ./port80
> cycles: out 2400, in 2400
>
> and on a PII 400 (Intel 440BX chipset) a constant:
>
> rene@6bap:~/src/port80$ su -c ./port80
> cycles: out 553, in 251
>
> Results are (mostly) independent of compiler optimisation, but testing with
> an -O2 compile should be most useful. Thanks!
>
> Rene.

Cyrix MII PR300 (225MHz), i430TX:    cycles: out 263, in 93
Pentium MMX 166MHz @133MHz, VIA VPX: cycles: out 163, in 163
Celeron 433MHz, i440BX:              cycles: out 620, in 305
Celeron 1.3GHz, i440BX:              cycles: out 2114, in 849
Celeron 1.7GHz (P4-based), i845:     cycles: out 2178, in 1651
Pentium 4 3.2GHz, i925X:             cycles: out 2824, in 1899
Xeon E5310 1.6GHz, Dell PE1950       cycles: out 2631, in 1606
Xeon 3050 2.13GHz, Dell PE860        cycles: out 3367, in 1959

-- 
Ondrej Zary

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (18 preceding siblings ...)
  2007-12-12 16:53 ` Ondrej Zary
@ 2007-12-12 16:59 ` Cyrill Gorcunov
  2007-12-12 17:27 ` Török Edwin
                   ` (4 subsequent siblings)
  24 siblings, 0 replies; 68+ messages in thread
From: Cyrill Gorcunov @ 2007-12-12 16:59 UTC (permalink / raw)
  To: Rene Herman; +Cc: LKML

[Rene Herman - Wed, Dec 12, 2007 at 12:31:18AM +0100]
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run 
> the attached program? This is about testing how long I/O port access to 
> port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in 
> reporting.
>
> Posted a previous incarnation of this before, buried in the outb 0x80 
> thread which had a serialising problem. This one should as far as I can see 
> measure the right thing though. Please yell if you disagree...
>
> For me, on a Duron 1300 (AMD756 chipset) I have a constant:
>
> rene@7ixe4:~/src/port80$ su -c ./port80
> cycles: out 2400, in 2400
>
> and on a PII 400 (Intel 440BX chipset) a constant:
>
> rene@6bap:~/src/port80$ su -c ./port80
> cycles: out 553, in 251
>
> Results are (mostly) independent of compiler optimisation, but testing with 
> an -O2 compile should be most useful. Thanks!
>
> Rene.

| /* gcc -W -Wall -O2 -o port80 port80.c */
| 
| #include <stdlib.h>
| #include <stdio.h>
| 
| #include <sys/io.h>
| 
| #define LOOPS 10000
| 
| inline unsigned long long rdtsc(void)
| {
| 	unsigned long long tsc;
| 
| 	asm volatile ("rdtsc": "=A" (tsc));
| 
| 	return tsc;
| }
| 
| inline void serialize(void)
| {
| 	asm volatile ("cpuid": : : "eax", "ebx", "ecx", "edx");
| }
| 
| int main(void)
| {
| 	unsigned long long start;
| 	unsigned long long overhead; 
| 	unsigned long long output;
| 	unsigned long long input;
| 	int i;
| 
| 	if (iopl(3) < 0) {
| 		perror("iopl");
| 		return EXIT_FAILURE;
| 	}
| 
| 	asm volatile ("cli");
| 	start = rdtsc();
| 	for (i = 0; i < LOOPS; i++) {
| 	 	serialize();	
| 		serialize();
| 	}
| 	overhead = rdtsc() - start;
| 
| 	start = rdtsc() + overhead;
| 	for (i = 0; i < LOOPS; i++) {
| 		serialize();
| 		asm volatile ("outb %al, $0x80");
| 		serialize();
| 	}
| 	output = rdtsc() - start;
| 
| 	start = rdtsc() + overhead;
| 	for (i = 0; i < LOOPS; i++) {
| 		serialize();
| 		asm volatile ("inb $0x80, %%al": : : "al");
| 		serialize();
| 	}
| 	input = rdtsc() - start;
| 	asm volatile ("sti");
| 
| 	output /= LOOPS;
| 	input  /= LOOPS;
| 	printf("cycles: out %llu, in %llu\n", output, input);
| 
| 	return EXIT_SUCCESS;
| }

Here we go (for 1000 times started) ;)

---
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1429, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1429, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1429, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1429, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1429, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1427, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1429, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1449
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1427, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1449
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1449
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1429, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1429, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1449
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1429, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1429, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1429, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1429, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
cycles: out 1428, in 1450
---

processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 36
model name	: AMD Turion(tm) 64 Mobile Technology ML-30
stepping	: 2
cpu MHz		: 800.000
cache size	: 1024 KB
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm ts fid vid ttp tm stc
bogomips	: 1601.04
clflush size	: 64

		Cyrill


^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12 16:53 ` Ondrej Zary
@ 2007-12-12 17:00   ` H. Peter Anvin
  0 siblings, 0 replies; 68+ messages in thread
From: H. Peter Anvin @ 2007-12-12 17:00 UTC (permalink / raw)
  To: Ondrej Zary
  Cc: Rene Herman, Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, john, linux-os

Ondrej Zary wrote:
> 
> Cyrix MII PR300 (225MHz), i430TX:    cycles: out 263, in 93
> Pentium MMX 166MHz @133MHz, VIA VPX: cycles: out 163, in 163
> Celeron 433MHz, i440BX:              cycles: out 620, in 305
> Celeron 1.3GHz, i440BX:              cycles: out 2114, in 849
> Celeron 1.7GHz (P4-based), i845:     cycles: out 2178, in 1651
> Pentium 4 3.2GHz, i925X:             cycles: out 2824, in 1899
> Xeon E5310 1.6GHz, Dell PE1950       cycles: out 2631, in 1606
> Xeon 3050 2.13GHz, Dell PE860        cycles: out 3367, in 1959
> 

So between 0.88 and 1.6 µs for the out case; 0.4 and 1.0 µs for the in case.

	-hpa


^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (19 preceding siblings ...)
  2007-12-12 16:59 ` Cyrill Gorcunov
@ 2007-12-12 17:27 ` Török Edwin
  2007-12-12 18:54   ` David P. Reed
  2007-12-12 18:39 ` SL Baur
                   ` (3 subsequent siblings)
  24 siblings, 1 reply; 68+ messages in thread
From: Török Edwin @ 2007-12-12 17:27 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile
> and run the attached program? This is about testing how long I/O port
> access to port 0x80 takes. It measures in CPU cycles so CPU speed is
> crucial in reporting.
>
> Posted a previous incarnation of this before, buried in the outb 0x80
> thread which had a serialising problem. This one should as far as I
> can see measure the right thing though. Please yell if you disagree...
>
Hi,

Tested on 2 systems.

System I
------------
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 47
model name      : AMD Athlon(tm) 64 Processor 3200+
stepping        : 2
cpu MHz         : 2000.000
cache size      : 512 KB
fpu             : yes
fpu_exception   : yes

Motherboard: Asus A9N-E


With -m32:

edwin@lightspeed2:~$ sudo ./port80
cycles: out 1107, in 1067
edwin@lightspeed2:~$ sudo ./port80
cycles: out 1107, in 1067
edwin@lightspeed2:~$ sudo ./port80
cycles: out 1107, in 1067
edwin@lightspeed2:~$ sudo ./port80
cycles: out 1107, in 1067
edwin@lightspeed2:~$ sudo ./port80
cycles: out 1107, in 1067
edwin@lightspeed2:~$ sudo ./port80
cycles: out 619, in 583
edwin@lightspeed2:~$ sudo ./port80
cycles: out 619, in 583
edwin@lightspeed2:~$ sudo ./port80
cycles: out 1107, in 1067
edwin@lightspeed2:~$ sudo ./port80
cycles: out 1107, in 1067
edwin@lightspeed2:~$ sudo ./port80
cycles: out 1107, in 1067
edwin@lightspeed2:~$ sudo ./port80
cycles: out 1107, in 1067
edwin@lightspeed2:~$ sudo ./port80
cycles: out 1107, in 1067

After making the __asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi));
I get this with 64:
edwin@lightspeed2:~$ sudo ./port80
cycles: out 1107, in 1067
edwin@lightspeed2:~$ sudo ./port80
cycles: out 1107, in 1067
edwin@lightspeed2:~$ sudo ./port80
cycles: out 1107, in 1067
edwin@lightspeed2:~$ sudo ./port80
cycles: out 1107, in 1067
edwin@lightspeed2:~$ sudo ./port80
cycles: out 1107, in 1067
edwin@lightspeed2:~$ sudo ./port80
cycles: out 1107, in 1067
edwin@lightspeed2:~$ sudo ./port80
cycles: out 1107, in 1067
edwin@lightspeed2:~$ sudo ./port80
cycles: out 1107, in 1067
edwin@lightspeed2:~$ sudo ./port80
cycles: out 618, in 583
edwin@lightspeed2:~$ sudo ./port80
cycles: out 618, in 583
edwin@lightspeed2:~$ sudo ./port80
cycles: out 1107, in 1067

If I stop cpudyn I get a constant 618/583.

System II
------------

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 14
model name      : Genuine Intel(R) CPU           T2300  @ 1.66GHz
stepping        : 8
cpu MHz         : 1667.000
cache size      : 2048 KB
physical id     : 0
siblings        : 2

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 14
model name      : Genuine Intel(R) CPU           T2300  @ 1.66GHz
stepping        : 8
cpu MHz         : 1667.000
cache size      : 2048 KB
physical id     : 0
siblings        : 2


Dell Inspiron 6400, Intel Core Duo (ICH7 chipset)

thunder:/home/edwin# ./port80
cycles: out 2480, in 1867
thunder:/home/edwin# ./port80
cycles: out 2482, in 1865
thunder:/home/edwin# ./port80
cycles: out 2968, in 1893
thunder:/home/edwin# ./port80
cycles: out 1991, in 1372
thunder:/home/edwin# ./port80
cycles: out 1979, in 1366
thunder:/home/edwin# ./port80
cycles: out 2473, in 1865
thunder:/home/edwin# ./port80
cycles: out 2484, in 1869

After setting CPU governor to performance:

# ./port80
cycles: out 2368, in 1783
thunder:/home/edwin# ./port80
cycles: out 2377, in 1783
thunder:/home/edwin# ./port80
cycles: out 2367, in 1774
thunder:/home/edwin# ./port80
cycles: out 2370, in 1780
thunder:/home/edwin# ./port80
cycles: out 2365, in 1782
thunder:/home/edwin# ./port80
cycles: out 2369, in 1774
thunder:/home/edwin# ./port80
cycles: out 2366, in 1784
thunder:/home/edwin# ./port80
cycles: out 2379, in 1786
thunder:/home/edwin# ./port80
cycles: out 2367, in 1773
thunder:/home/edwin# ./port80
cycles: out 2376, in 1783
thunder:/home/edwin# ./port80
cycles: out 2360, in 1784
thunder:/home/edwin# ./port80
cycles: out 2367, in 1783
thunder:/home/edwin# ./port80
cycles: out 2370, in 1783
thunder:/home/edwin# ./port80
cycles: out 2382, in 1782

Also tried in a loop, but values are not constant:
while true; do ./port80; done
cycles: out 2415, in 1818
cycles: out 2405, in 1817
cycles: out 2414, in 1810
cycles: out 2411, in 1819
cycles: out 2407, in 1821
cycles: out 2410, in 1820
cycles: out 2418, in 1821
cycles: out 2408, in 1847
cycles: out 2404, in 1805
cycles: out 2411, in 1858
cycles: out 2395, in 1765
cycles: out 2377, in 1786
cycles: out 2378, in 1813
cycles: out 2395, in 1800
cycles: out 2381, in 1793
cycles: out 2382, in 1790
cycles: out 2399, in 1835
cycles: out 1928, in 1327
cycles: out 2410, in 1781
cycles: out 1996, in 1287
cycles: out 2369, in 1768
cycles: out 2401, in 1805
cycles: out 2395, in 1802
cycles: out 2389, in 1786
cycles: out 2359, in 1768
cycles: out 2495, in 1858
cycles: out 2408, in 1809
cycles: out 2919, in 1859
cycles: out 2404, in 1798
cycles: out 2393, in 1791
cycles: out 2882, in 1797
cycles: out 2404, in 1789
cycles: out 2406, in 1785
cycles: out 2393, in 1840
cycles: out 2498, in 1818
cycles: out 2402, in 1805
cycles: out 2888, in 1858
cycles: out 2397, in 1802
cycles: out 2411, in 1810
cycles: out 2396, in 1788
cycles: out 2362, in 1780
cycles: out 2861, in 1785
cycles: out 2380, in 1780
cycles: out 2357, in 1785
cycles: out 2342, in 1783
cycles: out 1916, in 1294
cycles: out 2358, in 1768
cycles: out 2371, in 1763
cycles: out 2386, in 1783
cycles: out 1919, in 1320
cycles: out 2355, in 1782
cycles: out 2330, in 1787
cycles: out 2350, in 1781
cycles: out 1881, in 1269
cycles: out 2378, in 1768
cycles: out 2381, in 1739
cycles: out 2365, in 1768
cycles: out 2362, in 1759
cycles: out 2368, in 1739
cycles: out 2354, in 1775
cycles: out 2375, in 1783
cycles: out 2369, in 1785
cycles: out 2361, in 1769
cycles: out 2382, in 1785
cycles: out 2370, in 1783


--Edwin

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (20 preceding siblings ...)
  2007-12-12 17:27 ` Török Edwin
@ 2007-12-12 18:39 ` SL Baur
  2007-12-12 19:06   ` Rene Herman
  2007-12-12 21:32 ` Jesper Juhl
                   ` (2 subsequent siblings)
  24 siblings, 1 reply; 68+ messages in thread
From: SL Baur @ 2007-12-12 18:39 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On 12/11/07, Rene Herman <rene.herman@gmail.com> wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to port
> 0x80 takes. It measures in CPU cycles so CPU speed is crucial in reporting.

model name      : Intel(R) Pentium(R) 4 CPU 3.20GHz
cpu MHz         : 3201.345

cycles: out 3026, in 2204
cycles: out 3031, in 2182
cycles: out 3019, in 2196
cycles: out 3030, in 2201
cycles: out 3013, in 2186

-sb

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12 11:25   ` Jiri Slaby
  2007-12-12 15:50     ` Rene Herman
  2007-12-12 15:53     ` Rene Herman
@ 2007-12-12 18:44     ` H. Peter Anvin
  2007-12-12 19:19       ` Rene Herman
  2 siblings, 1 reply; 68+ messages in thread
From: H. Peter Anvin @ 2007-12-12 18:44 UTC (permalink / raw)
  To: Jiri Slaby
  Cc: Rene Herman, Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, john, linux-os

Jiri Slaby wrote:
> On Dec 12, 2007 9:48 AM, Jiri Slaby <jirislaby@gmail.com> wrote:
>> On 12/12/2007 12:31 AM, Rene Herman wrote:
>>> Good day.
>>>
>>> Would some people on x86 (both 32 and 64) be kind enough to compile and
>>> run the attached program? This is about testing how long I/O port access
> 
> model name      : Intel(R) Xeon(R) CPU           E5335  @ 2.00GHz 
> cycles: out 3217, in 1898

1.6 µs, on the high end....

> model name      : Dual Core AMD Opteron(tm) Processor 275
> cycles: out 5508, in 5524

Definitely an outlier; 2.5 µs here.

	-hpa

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12 17:27 ` Török Edwin
@ 2007-12-12 18:54   ` David P. Reed
  0 siblings, 0 replies; 68+ messages in thread
From: David P. Reed @ 2007-12-12 18:54 UTC (permalink / raw)
  To: Török Edwin
  Cc: Rene Herman, Linux Kernel, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

I have been having a fun time testing this on my AMD64x2 system.

Since out's to port 80 hang the system hard after a while, I can run a 
test just after booting, but the next run will typically hang it.

I did also test two ports thought to be unused.   They do *not* hang the 
system.  Thus apparently there is some device responding to port 80!

Running the (slightly modified to test 3 ports instead of just port 80) 
test when the CPU is running at 800 MHz, here's what I get for port 80 
and port ec and port ef.

port 80:   cycles: out 1430, in 792
port ef:    cycles: out 1431, in 1378
port ec:   cycles: out 1432, in 1372

[Note: port 80, when it doesn't hang, which is very often, responds to a 
read twice as fast as a port which is "not there".   Typically though, 
the second time I run the test, the system freezes solid.  Seems like 
evidence of a present device, not a missing one.  Also, port 80 responds 
when booted with acpi=off, but never seems to hang - sounds like ACPI 
causes it to be active in some way]
----------------------------

System info:  HP Pavilion dv9000z laptop (AMD64x2)

PCI bus controller is nVidia MCP51.
/proc/cpuinfo

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 72
model name      : AMD Turion(tm) 64 X2 Mobile Technology TL-60
stepping        : 2
cpu MHz         : 800.000
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext 
fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy 
svm extapic cr8_legacy
bogomips        : 1608.35
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 72
model name      : AMD Turion(tm) 64 X2 Mobile Technology TL-60
stepping        : 2
cpu MHz         : 800.000
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext 
fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy 
svm extapic cr8_legacy
bogomips        : 1608.35
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc


^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12 18:39 ` SL Baur
@ 2007-12-12 19:06   ` Rene Herman
  0 siblings, 0 replies; 68+ messages in thread
From: Rene Herman @ 2007-12-12 19:06 UTC (permalink / raw)
  To: SL Baur; +Cc: Linux Kernel

On 12-12-07 19:39, SL Baur wrote:

> model name      : Intel(R) Pentium(R) 4 CPU 3.20GHz
> cpu MHz         : 3201.345
> 
> cycles: out 3026, in 2204
> cycles: out 3031, in 2182
> cycles: out 3019, in 2196
> cycles: out 3030, in 2201
> cycles: out 3013, in 2186

Thank you. I just posted the combined results, although I see it's not made 
it to the list yet, probably due to a somewhat overly broad CC...

These results fit the pattern.

Rene.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12 18:44     ` H. Peter Anvin
@ 2007-12-12 19:19       ` Rene Herman
  2007-12-13 15:19         ` Jiri Slaby
  0 siblings, 1 reply; 68+ messages in thread
From: Rene Herman @ 2007-12-12 19:19 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Jiri Slaby, Rene Herman, Linux Kernel, dpreed, Alan Cox, pavel,
	andi, rol, Krzysztof Halasa, david, john, linux-os

On 12-12-07 19:44, H. Peter Anvin wrote:

>> model name      : Intel(R) Xeon(R) CPU           E5335  @ 2.00GHz 
>> cycles: out 3217, in 1898
> 
> 1.6 µs, on the high end....
> 
>> model name      : Dual Core AMD Opteron(tm) Processor 275
>> cycles: out 5508, in 5524
> 
> Definitely an outlier; 2.5 µs here.

Jah, I don't trust that one. Just posted the complete results:

http://lkml.org/lkml/2007/12/12/309

Rene.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12  5:23 ` Kyle McMartin
  2007-12-12  7:18   ` Rene Herman
@ 2007-12-12 19:25   ` H. Peter Anvin
  2007-12-12 19:32     ` Andi Kleen
  1 sibling, 1 reply; 68+ messages in thread
From: H. Peter Anvin @ 2007-12-12 19:25 UTC (permalink / raw)
  To: Kyle McMartin
  Cc: Rene Herman, Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, john, linux-os

Kyle McMartin wrote:
> On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
>> 	asm volatile ("rdtsc": "=A" (tsc));
> 
> rdtsc returns a 64-bit value in two 32-bit regs, you need to do
> 
> inline unsigned long long rdtsc(void)
> {
> 	unsigned int lo, hi;
> 	asm volatile ("rdtsc": "=a" (lo), "=d" (hi));
> 	return (unsigned long long)hi << 32 | lo;
> }
> 
> as in msr.h, otherwise you'll only be looking at the value in %rax.
> 

"=A" works on 32-bit systems (only), obviously, and gcc will generally 
produce slightly better code as a result (gcc could really use a 
register renaming/copy propagation step *after* multi-register entities 
are broken apart, at least on architectures which don't have register 
pairs as a hardware constraint.)

	-hpa

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12 19:25   ` H. Peter Anvin
@ 2007-12-12 19:32     ` Andi Kleen
  2007-12-12 19:43       ` H. Peter Anvin
  0 siblings, 1 reply; 68+ messages in thread
From: Andi Kleen @ 2007-12-12 19:32 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Kyle McMartin, Rene Herman, Linux Kernel, dpreed, Alan Cox,
	pavel, andi, rol, Krzysztof Halasa, david, john, linux-os

> "=A" works on 32-bit systems (only), obviously, and gcc will generally 
> produce slightly better code as a result (gcc could really use a 
> register renaming/copy propagation step *after* multi-register entities 

I believe gcc 4.3 (or maybe 4.2) does that already -- it splits them much 
earlier.

-Andi

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12 19:32     ` Andi Kleen
@ 2007-12-12 19:43       ` H. Peter Anvin
  0 siblings, 0 replies; 68+ messages in thread
From: H. Peter Anvin @ 2007-12-12 19:43 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Kyle McMartin, Rene Herman, Linux Kernel, dpreed, Alan Cox,
	pavel, rol, Krzysztof Halasa, david, john, linux-os

Andi Kleen wrote:
>> "=A" works on 32-bit systems (only), obviously, and gcc will generally 
>> produce slightly better code as a result (gcc could really use a 
>> register renaming/copy propagation step *after* multi-register entities 
> 
> I believe gcc 4.3 (or maybe 4.2) does that already -- it splits them much 
> earlier.

Probably 4.3, then.  I don't see 4.2 doing that, or at least not very 
successfully.  Which is fine, I'm sure they had bigger fish to fry. 
Good to hear it has gotten some attention recently.

	-hpa

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12  0:16       ` Rene Herman
  2007-12-12 11:43         ` Alejandro Riveira Fernández
@ 2007-12-12 21:02         ` H. Peter Anvin
  1 sibling, 0 replies; 68+ messages in thread
From: H. Peter Anvin @ 2007-12-12 21:02 UTC (permalink / raw)
  To: Rene Herman
  Cc: Alejandro Riveira Fernández, Linux Kernel, dpreed, Alan Cox,
	pavel, andi, rol, Krzysztof Halasa, david, john, linux-os

Rene Herman wrote:
> On 12-12-07 01:09, Alejandro Riveira Fernández wrote:
> 
>>>>  On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get:
>>>>
>>>>  cycles: out 1844674407370808, in 1844674407369087
>>>>  
>>>> It is not constant but variations are not significant afaics
>>> Eh, oh, I guess you need to compile as a 32-bit binary...
>>  
>>  I tried without -O2 as Nigel Cunningham...
>>
>>  cycles: out 1562, in 865
>>  cycles: out 1562, in 866
>>  cycles: out 1555, in 858
>>  cycles: out 1562, in 866
>>  
>>  With -m32 -O2
>>  cycles: out 1566, in 876
>>  cycles: out 1555, in 865
>>  cycles: out 1594, in 931
>>  cycles: out 1559, in 874
> 
> Great, thanks much for reporting. Sort of interesting in itself that 
> without -O2 you do still get correct results on 64-bit but for some 
> other time.
> 
> You're the first one to go significantly below 1 us it seems.

Make sure the CPU is actually running at full frequency.

It probably would have been better to have used gettimeofday() around a 
sufficiently big loop, so that we would have gotten wall time rather 
than cycles.

	-hpa

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (21 preceding siblings ...)
  2007-12-12 18:39 ` SL Baur
@ 2007-12-12 21:32 ` Jesper Juhl
  2007-12-12 23:54 ` Jan Engelhardt
  2007-12-22 22:27 ` Bauke Jan Douma
  24 siblings, 0 replies; 68+ messages in thread
From: Jesper Juhl @ 2007-12-12 21:32 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On 12/12/2007, Rene Herman <rene.herman@gmail.com> wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to port
> 0x80 takes. It measures in CPU cycles so CPU speed is crucial in reporting.
>

root@dragon:/home/juhl# uname -a
Linux dragon 2.6.24-rc3-g2ffbb837 #7 SMP PREEMPT Mon Nov 19 22:16:27
CET 2007 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
AuthenticAMD GNU/Linux
root@dragon:/home/juhl# cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 35
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
stepping        : 2
cpu MHz         : 2200.000
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy ts fid vid ttp
bogomips        : 4401.67
clflush size    : 64

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 35
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
stepping        : 2
cpu MHz         : 2200.000
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy ts fid vid ttp
bogomips        : 4399.52
clflush size    : 64

root@dragon:/home/juhl# for i in $(seq 1 10); do ./port80 ; sleep 1 ; done
cycles: out 1839, in 1715
cycles: out 1728, in 1604
cycles: out 1762, in 1714
cycles: out 1770, in 1722
cycles: out 1759, in 1723
cycles: out 1764, in 1723
cycles: out 1762, in 1712
cycles: out 1761, in 1723
cycles: out 1771, in 1715
cycles: out 1770, in 1709


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (22 preceding siblings ...)
  2007-12-12 21:32 ` Jesper Juhl
@ 2007-12-12 23:54 ` Jan Engelhardt
  2007-12-13  0:13   ` Jan Engelhardt
  2007-12-13  2:06   ` H. Peter Anvin
  2007-12-22 22:27 ` Bauke Jan Douma
  24 siblings, 2 replies; 68+ messages in thread
From: Jan Engelhardt @ 2007-12-12 23:54 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os


On Dec 12 2007 00:31, Rene Herman wrote:
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run the
> attached program? This is about testing how long I/O port access to port 0x80
> takes. It measures in CPU cycles so CPU speed is crucial in reporting.
>

Transmeta TM5800 CPU with nominal frequency 933 MHz, but it has a
hardware(!) 'ondemand' governor over the range of frequencies that
the user allowed scaling over, irrespective of the software governor.
(That is, if the CPU can do 300,533 and 933 MHz, and setting the
min/max to 300/533 will cause the hardware to 'ondemand' between 300
and 533 only. And that even if 'performance' is set on the software
side - so the only way to enforce 'performance' is to actually set
min=933.)

00:46 takeshi:../cpu0/cpufreq # echo 300000 >scaling_min_freq
00:46 takeshi:../cpu0/cpufreq # echo 933000 >scaling_max_freq
00:42 takeshi:/dev/shm # for ((x=1;x<=10;++x)); do ./port80 ; done
cycles: out 1514, in 584
cycles: out 1371, in 516
cycles: out 1291, in 472
cycles: out 1304, in 437
cycles: out 1308, in 410
cycles: out 1315, in 419
cycles: out 1315, in 419
cycles: out 1314, in 419
cycles: out 1315, in 420
cycles: out 1315, in 419
00:44 takeshi:/dev/shm # for ((x=1;x<=10;++x)); do ./port80 ; done
cycles: out 1511, in 596
cycles: out 1373, in 517
cycles: out 1293, in 470
cycles: out 1294, in 424
cycles: out 1304, in 414
cycles: out 1315, in 420
cycles: out 1313, in 418
cycles: out 1313, in 418
cycles: out 1314, in 420
cycles: out 1314, in 419

Increasing x above 10 yields only 1313-1315 values, so nothing more to see.
Note the values < 1313!! They only happen during scaling.
(I think scaling is the most important sideexercise in this test,
even on hardware which does not have hardware governors - e.g. your
average Intel/AMD CPUs.)

Single frequencies:
00:46 takeshi:../cpu0/cpufreq # echo 933000 >scaling_min_freq
00:46 takeshi:../cpu0/cpufreq # echo 933000 >scaling_max_freq
00:46 takeshi:../cpu0/cpufreq # for ((x=1;x<=10;++x)); do /dev/shm/port80 ;
donecycles: out 1314, in 419
cycles: out 1315, in 420
cycles: out 1314, in 419
cycles: out 1312, in 417
cycles: out 1315, in 420
cycles: out 1314, in 419
cycles: out 1313, in 419
cycles: out 1313, in 419
cycles: out 1314, in 419
cycles: out 1312, in 418

00:47 takeshi:../cpu0/cpufreq # echo 533000 >scaling_min_freq
00:47 takeshi:../cpu0/cpufreq # echo 533000 >scaling_max_freq
00:49 takeshi:../cpu0/cpufreq # for ((x=1;x<=10;++x)); do /dev/shm/port80 ;
donecycles: out 1372, in 508
cycles: out 1370, in 509
cycles: out 1372, in 515
cycles: out 1372, in 503
cycles: out 1372, in 503
cycles: out 1370, in 509
cycles: out 1368, in 513
cycles: out 1372, in 516
cycles: out 1372, in 504
cycles: out 1372, in 516

00:47 takeshi:../cpu0/cpufreq # echo 300000 >scaling_min_freq
00:47 takeshi:../cpu0/cpufreq # echo 300000 >scaling_max_freq
00:48 takeshi:../cpu0/cpufreq # for ((x=1;x<=10;++x)); do /dev/shm/port80 ;
donecycles: out 1515, in 650
cycles: out 1516, in 649
cycles: out 1517, in 651
cycles: out 1513, in 645
cycles: out 1514, in 649
cycles: out 1516, in 644
cycles: out 1517, in 651
cycles: out 1516, in 644
cycles: out 1512, in 647
cycles: out 1514, in 649

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12 23:54 ` Jan Engelhardt
@ 2007-12-13  0:13   ` Jan Engelhardt
  2007-12-13  2:06   ` H. Peter Anvin
  1 sibling, 0 replies; 68+ messages in thread
From: Jan Engelhardt @ 2007-12-13  0:13 UTC (permalink / raw)
  To: Rene Herman; +Cc: Linux Kernel


On Dec 13 2007 00:54, Jan Engelhardt wrote:
>
>Transmeta TM5800 CPU with nominal frequency 933 MHz, but it has a
>hardware(!) 'ondemand' governor over the range of frequencies that
>the user allowed scaling over, irrespective of the software governor.
>(That is, if the CPU can do 300,533 and 933 MHz, and setting the
>min/max to 300/533 will cause the hardware to 'ondemand' between 300
>and 533 only. And that even if 'performance' is set on the software
>side - so the only way to enforce 'performance' is to actually set
>min=933.)
>
>00:46 takeshi:../cpu0/cpufreq # echo 300000 >scaling_min_freq
>00:46 takeshi:../cpu0/cpufreq # echo 933000 >scaling_max_freq
>00:42 takeshi:/dev/shm # for ((x=1;x<=10;++x)); do ./port80 ; done
>cycles: out 1514, in 584
^ most likely 300 MHz state
>cycles: out 1371, in 516
^ 533 MHz state
>cycles: out 1291, in 472
^ ??
>cycles: out 1304, in 437
^ ??
>cycles: out 1308, in 410
^ ??
>cycles: out 1315, in 419
^ 933 MHz state
>cycles: out 1315, in 419
>cycles: out 1314, in 419
>cycles: out 1315, in 420
>cycles: out 1315, in 419

...this is in stark contrast to values of other users, where,
skimming through the mails, higher cpu frequencies yields
higher out/in values, but not so on TM5800. Highly interesting.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12 23:54 ` Jan Engelhardt
  2007-12-13  0:13   ` Jan Engelhardt
@ 2007-12-13  2:06   ` H. Peter Anvin
  1 sibling, 0 replies; 68+ messages in thread
From: H. Peter Anvin @ 2007-12-13  2:06 UTC (permalink / raw)
  To: Jan Engelhardt
  Cc: Rene Herman, Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, john, linux-os

Jan Engelhardt wrote:
> On Dec 12 2007 00:31, Rene Herman wrote:
>> Would some people on x86 (both 32 and 64) be kind enough to compile and run the
>> attached program? This is about testing how long I/O port access to port 0x80
>> takes. It measures in CPU cycles so CPU speed is crucial in reporting.
>>
> 
> Transmeta TM5800 CPU with nominal frequency 933 MHz, but it has a
> hardware(!) 'ondemand' governor over the range of frequencies that
> the user allowed scaling over, irrespective of the software governor.
> (That is, if the CPU can do 300,533 and 933 MHz, and setting the
> min/max to 300/533 will cause the hardware to 'ondemand' between 300
> and 533 only. And that even if 'performance' is set on the software
> side - so the only way to enforce 'performance' is to actually set
> min=933.)
> 

Actually it has two different ones (economy and performance), you can 
use the "longrun" utility to select which one.

Either way, all Transmeta processors have a fixed TSC, so there is no issue.

	-hpa

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12  7:18   ` Rene Herman
@ 2007-12-13  2:41     ` H. Peter Anvin
  0 siblings, 0 replies; 68+ messages in thread
From: H. Peter Anvin @ 2007-12-13  2:41 UTC (permalink / raw)
  To: Rene Herman
  Cc: Kyle McMartin, Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, john, linux-os

Rene Herman wrote:
> On 12-12-07 06:23, Kyle McMartin wrote:
> 
>> On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
>>>     asm volatile ("rdtsc": "=A" (tsc));
>>
>> rdtsc returns a 64-bit value in two 32-bit regs, you need to do
>>
>> inline unsigned long long rdtsc(void)
>> {
>>     unsigned int lo, hi;
>>     asm volatile ("rdtsc": "=a" (lo), "=d" (hi));
>>     return (unsigned long long)hi << 32 | lo;
>> }
>>
>> as in msr.h, otherwise you'll only be looking at the value in %rax.
> 
> On 32-bit, "=A" is edx:eax. Not sure what the point is in not letting it 
> be that on 64-bit in fact, but yes, the thing should be compiled as 32-bit.

On 64-bit, "=A" is rdx:rax, which means that a 64-bit value ends up in 
rax only (a 128-bit value, which gcc does support on 128-bit platforms, 
would be in rdx:rax.)

gcc can't deal internally with values that span partial registers.

	-hpa

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12 19:19       ` Rene Herman
@ 2007-12-13 15:19         ` Jiri Slaby
  0 siblings, 0 replies; 68+ messages in thread
From: Jiri Slaby @ 2007-12-13 15:19 UTC (permalink / raw)
  To: Rene Herman
  Cc: H. Peter Anvin, Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, john, linux-os

Rene Herman napsal(a):
> On 12-12-07 19:44, H. Peter Anvin wrote:
> 
>>> model name      : Intel(R) Xeon(R) CPU           E5335  @ 2.00GHz
>>> cycles: out 3217, in 1898
>>
>> 1.6 µs, on the high end....
>>
>>> model name      : Dual Core AMD Opteron(tm) Processor 275
>>> cycles: out 5508, in 5524
>>
>> Definitely an outlier; 2.5 µs here.

Now, it's around
cycles: out 4763, in 5515

It's
cpu MHz         : 2205.209

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12 11:57 ` Ville Syrjälä
@ 2007-12-13 16:42   ` Ville Syrjälä
  0 siblings, 0 replies; 68+ messages in thread
From: Ville Syrjälä @ 2007-12-13 16:42 UTC (permalink / raw)
  To: Rene Herman
  Cc: Linux Kernel, dpreed, Alan Cox, pavel, andi, rol,
	Krzysztof Halasa, david, hpa, john, linux-os

On Wed, Dec 12, 2007 at 01:57:01PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
> > Good day.
> >
> > Would some people on x86 (both 32 and 64) be kind enough to compile and run 
> > the attached program? This is about testing how long I/O port access to 
> > port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in 
> > reporting.
> 
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 15
> model name      : Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz
> stepping        : 6
> 
> cpu MHz         : 2394.000
> cycles: out 1830, in 1166
> 
> cpu MHz         : 1596.000
> cycles: out 1925, in 1266

BTW that was my home desktop. I just noticed that my work desktop gives out
significantly different results.

vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 CPU          6700  @ 2.66GHz
stepping        : 6

cpu MHz         : 2667.000
cycles: out 4263, in 2487

cpu MHz         : 1600.000
cycles: out 4391, in 2623

There seems to be more variation in the results between runs on this system
too. I suppose the difference must be up to the chipset.

My home system:
00:00.0 Host bridge: Intel Corporation 82P965/G965 Memory Controller Hub (rev 02)
00:1f.0 ISA bridge: Intel Corporation 82801HB/HR (ICH8/R) LPC Interface Controller (rev 02)

My work system:
00:00.0 Host bridge: Intel Corporation 82975X Memory Controller Hub
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
                   ` (23 preceding siblings ...)
  2007-12-12 23:54 ` Jan Engelhardt
@ 2007-12-22 22:27 ` Bauke Jan Douma
  24 siblings, 0 replies; 68+ messages in thread
From: Bauke Jan Douma @ 2007-12-22 22:27 UTC (permalink / raw)
  To: Rene Herman; +Cc: Linux Kernel

Rene Herman wrote on 12-12-07 00:31:
> Good day.
> 
> Would some people on x86 (both 32 and 64) be kind enough to compile and 
> run the attached program? This is about testing how long I/O port access 
> to port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in 
> reporting.

Compiled as you wished.
And here are the results from 10 iterations...:

cycles: out 1965, in 1263
cycles: out 1968, in 1251
cycles: out 1957, in 1257
cycles: out 1992, in 1253
cycles: out 1959, in 1248
cycles: out 1965, in 1264
cycles: out 1957, in 1256
cycles: out 1959, in 1248
cycles: out 1962, in 1298
cycles: out 1962, in 1275

Linux skyscraper 2.6.23.11 #1 SMP Sun Dec 16 11:54:12 CET 2007 i686 GNU/Linux

32bits system

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 Quad CPU           @ 2.40GHz
stepping        : 7
cpu MHz         : 2400.182
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr s
bogomips        : 4802.73
clflush size    : 64

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 Quad CPU           @ 2.40GHz
stepping        : 7
cpu MHz         : 2400.182
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 4
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr s
bogomips        : 10614.49
clflush size    : 64

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 Quad CPU           @ 2.40GHz
stepping        : 7
cpu MHz         : 2400.182
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 4
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr s
bogomips        : 4800.17
clflush size    : 64

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 Quad CPU           @ 2.40GHz
stepping        : 7
cpu MHz         : 2400.182
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 3
cpu cores       : 4
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr s
bogomips        : 4800.17
clflush size    : 64


^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
       [not found]   ` <9A4pU-69z-15@gated-at.bofh.it>
@ 2007-12-14 14:08     ` James Kosin
  0 siblings, 0 replies; 68+ messages in thread
From: James Kosin @ 2007-12-14 14:08 UTC (permalink / raw)
  To: linux-kernel

Rene Herman wrote:
> On 13-12-07 17:27, James Kosin wrote:
> 
>> model name      : Pentium III (Katmai)
>> cpu MHz         : 499.156
> 
>> [root@beta jkosin]# ./a.out
>> cycles: out 683, in 299
> 
> Thanks much, you made spot 32 ;-)
> 
> http://lkml.org/lkml/2007/12/12/309
> 
> By the way, if anyone in this/these thread(s) wrote something today (*)
> they would like me to reply to -- my horseshit ISP is completely
> crapping out on me and I haven't seen your message. Resends ofcourse
> welcome.
> 
> (*) [now - 16 hours, now]
> 
> Rene.
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
Maybe,  I should have added the lspci to the list of information.
kernel version is latest 2.4 kernel.

[root@beta root]# lspci
00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge
(rev 03)
00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge
(rev 03)
00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169
(rev 10)
00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
00:0b.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro
215GP (rev 5c)

-- 
Scanned by ClamAV - http://www.clamav.net


^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-13 22:30     ` Jesper Juhl
@ 2007-12-13 22:37       ` Rene Herman
  0 siblings, 0 replies; 68+ messages in thread
From: Rene Herman @ 2007-12-13 22:37 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: James Kosin, linux-kernel

On 13-12-07 23:30, Jesper Juhl wrote:

> On 13/12/2007, Rene Herman <rene.herman@gmail.com> wrote:

>> http://lkml.org/lkml/2007/12/12/309
>>
>> By the way, if anyone in this/these thread(s) wrote something today (*) they
>> would like me to reply to -- my horseshit ISP is completely crapping out on
>> me and I haven't seen your message. Resends ofcourse welcome.
>>
> Don't know if you saw mine (at least it's not on your list), but it's
> archived here: http://lkml.org/lkml/2007/12/12/399

Nope didn't, thanks. Same CPU as the unexpected 59 spot it seems, but yours 
with an expected 0.80 figure.

Rene.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-13 22:07   ` Rene Herman
@ 2007-12-13 22:30     ` Jesper Juhl
  2007-12-13 22:37       ` Rene Herman
  0 siblings, 1 reply; 68+ messages in thread
From: Jesper Juhl @ 2007-12-13 22:30 UTC (permalink / raw)
  To: Rene Herman; +Cc: James Kosin, linux-kernel

On 13/12/2007, Rene Herman <rene.herman@gmail.com> wrote:
> On 13-12-07 17:27, James Kosin wrote:
>
> > model name      : Pentium III (Katmai)
> > cpu MHz         : 499.156
>
> > [root@beta jkosin]# ./a.out
> > cycles: out 683, in 299
>
> Thanks much, you made spot 32 ;-)
>
> http://lkml.org/lkml/2007/12/12/309
>
> By the way, if anyone in this/these thread(s) wrote something today (*) they
> would like me to reply to -- my horseshit ISP is completely crapping out on
> me and I haven't seen your message. Resends ofcourse welcome.
>
Don't know if you saw mine (at least it's not on your list), but it's
archived here: http://lkml.org/lkml/2007/12/12/399


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-13 16:27 ` James Kosin
@ 2007-12-13 22:07   ` Rene Herman
  2007-12-13 22:30     ` Jesper Juhl
  0 siblings, 1 reply; 68+ messages in thread
From: Rene Herman @ 2007-12-13 22:07 UTC (permalink / raw)
  To: James Kosin; +Cc: linux-kernel

On 13-12-07 17:27, James Kosin wrote:

> model name      : Pentium III (Katmai)
> cpu MHz         : 499.156

> [root@beta jkosin]# ./a.out
> cycles: out 683, in 299

Thanks much, you made spot 32 ;-)

http://lkml.org/lkml/2007/12/12/309

By the way, if anyone in this/these thread(s) wrote something today (*) they 
would like me to reply to -- my horseshit ISP is completely crapping out on 
me and I haven't seen your message. Resends ofcourse welcome.

(*) [now - 16 hours, now]

Rene.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
       [not found] <9zmRR-3pA-25@gated-at.bofh.it>
@ 2007-12-13 16:27 ` James Kosin
  2007-12-13 22:07   ` Rene Herman
  0 siblings, 1 reply; 68+ messages in thread
From: James Kosin @ 2007-12-13 16:27 UTC (permalink / raw)
  To: linux-kernel

Rene Herman wrote:
> Good day.
> 
> Would some people on x86 (both 32 and 64) be kind enough to compile and
> run the attached program? This is about testing how long I/O port access
> to port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in
> reporting.
> 
> Posted a previous incarnation of this before, buried in the outb 0x80
> thread which had a serialising problem. This one should as far as I can
> see measure the right thing though. Please yell if you disagree...
> 
> For me, on a Duron 1300 (AMD756 chipset) I have a constant:
> 
> rene@7ixe4:~/src/port80$ su -c ./port80
> cycles: out 2400, in 2400
> 
> and on a PII 400 (Intel 440BX chipset) a constant:
> 
> rene@6bap:~/src/port80$ su -c ./port80
> cycles: out 553, in 251
> 
> Results are (mostly) independent of compiler optimisation, but testing
> with an -O2 compile should be most useful. Thanks!
> 
> Rene.
> 
[root@beta jkosin]# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 7
model name      : Pentium III (Katmai)
stepping        : 3
cpu MHz         : 499.156
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr sse
bogomips        : 996.14

[root@beta jkosin]# ./a.out
cycles: out 683, in 299
[root@beta jkosin]# ./a.out
cycles: out 683, in 299
[root@beta jkosin]# ./a.out
cycles: out 683, in 299
[root@beta jkosin]#

-- 
Scanned by ClamAV - http://www.clamav.net


^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12 11:20 linux
  2007-12-12 12:35 ` Paolo Ornati
@ 2007-12-12 14:48 ` Rene Herman
  1 sibling, 0 replies; 68+ messages in thread
From: Rene Herman @ 2007-12-12 14:48 UTC (permalink / raw)
  To: linux; +Cc: Linux Kernel

On 12-12-07 12:20, linux@horizon.com wrote:

> Here are a variety of machines:

Thanks much for all! Collecting all data now...

> With -O2, the cycle counts come out (before division) as
> out: 0xFFFFFFFFFFEA6F4F
> in:  0xFFFFFFFFFCE68BB6
> I think the "A" constraint doesn't work quite the same in
> 64-bit code.  The compiler seems to be using %rdx rather than
> %edx:%eax.

Yes indeed, that tripped me up. Have been using the "=A" locally for a while 
for similar timing tests. Will use a manual "=a" (lo), "=d" (hi) I guess for 
amd64 compatibility from now on.

If I'd care deeply I'd probably categorize this as a backwards compatibility 
bug in GCC though. Things were probably never guaranteed but they certainly 
worked that way...

Rene.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
  2007-12-12 11:20 linux
@ 2007-12-12 12:35 ` Paolo Ornati
  2007-12-12 14:48 ` Rene Herman
  1 sibling, 0 replies; 68+ messages in thread
From: Paolo Ornati @ 2007-12-12 12:35 UTC (permalink / raw)
  To: linux; +Cc: linux-kernel, rene.herman, linux

On 12 Dec 2007 06:20:49 -0500
linux@horizon.com wrote:

> With -O2, the cycle counts come out (before division) as
> out: 0xFFFFFFFFFFEA6F4F
> in:  0xFFFFFFFFFCE68BB6
> I think the "A" constraint doesn't work quite the same in
> 64-bit code.  The compiler seems to be using %rdx rather than
> %edx:%eax.

In another message he says to compile it with "-m32"  :)

-- 
	Paolo Ornati
	Linux 2.6.24-rc5-g4af75653 on x86_64

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
@ 2007-12-12 11:20 linux
  2007-12-12 12:35 ` Paolo Ornati
  2007-12-12 14:48 ` Rene Herman
  0 siblings, 2 replies; 68+ messages in thread
From: linux @ 2007-12-12 11:20 UTC (permalink / raw)
  To: linux-kernel, rene.herman; +Cc: linux

Here are a variety of machines:

600 MHz PIII (Katmai), 440BX chipset, 82371AB/EB/MB PIIX4 ISA bridge:
cycles: out 794, in 348
cycles: out 791, in 348
cycles: out 791, in 349
cycles: out 791, in 348
cycles: out 791, in 348

433 MHz Celeron (Mendocino), 440 BX chipset, same ISA bridge:
cycles: out 624, in 297
cycles: out 623, in 296
cycles: out 624, in 297
cycles: out 623, in 297
cycles: out 623, in 296

1100 MHz Athlon, nForce2 chipset, nForce2 ISA bridge:
cycles: out 1295, in 1162
cycles: out 1295, in 1162
cycles: out 1295, in 1162
cycles: out 1295, in 1162
cycles: out 1295, in 1162

800 MHz Transmeta Crusoe TM5800, Transmeta/ALi M7101 chipset.
cycles: out 1212, in 388
cycles: out 1195, in 375
cycles: out 1197, in 377
cycles: out 1196, in 376
cycles: out 1196, in 377

2200 MHz Athlon 64, K8T890 chipset, VT8237 ISA bridge:
cycles: out 1844674407370814, in 1844674407365758
cycles: out 1844674407370813, in 1844674407365756
cycles: out 1844674407370805, in 1844674407365750
cycles: out 1844674407370813, in 1844674407365755
cycles: out 1844674407370814, in 1844674407365756

Um, huh?  That's gcc 4.2.3 (Debian version 4.2.2-4), -O2.  Very odd.

I can run it with -O0:
cycles: out 4894, in 4894
cycles: out 4905, in 4917
cycles: out 4910, in 4896
cycles: out 4909, in 4896
cycles: out 4894, in 4898
cycles: out 4911, in 4898

or with -O2 -m32:
cycles: out 4914, in 4927
cycles: out 4913, in 4927
cycles: out 4913, in 4913
cycles: out 4914, in 4913
cycles: out 4913, in 4929
cycles: out 4912, in 4912
cycles: out 4913, in 4915

With -O2, the cycle counts come out (before division) as
out: 0xFFFFFFFFFFEA6F4F
in:  0xFFFFFFFFFCE68BB6
I think the "A" constraint doesn't work quite the same in
64-bit code.  The compiler seems to be using %rdx rather than
%edx:%eax.

^ permalink raw reply	[flat|nested] 68+ messages in thread

* Re: [RFT] Port 0x80 I/O speed
@ 2007-12-12  5:06 Chris Holvenstot
  0 siblings, 0 replies; 68+ messages in thread
From: Chris Holvenstot @ 2007-12-12  5:06 UTC (permalink / raw)
  To: Kernel


cycles: out 1296, in 1243
cycles: out 1312, in 1245
cycles: out 1289, in 1239
cycles: out 1309, in 1245
cycles: out 1308, in 1244
cycles: out 1325, in 1239
cycles: out 1310, in 1245
cycles: out 1289, in 1239
cycles: out 1301, in 1252
cycles: out 1325, in 1249
cycles: out 1307, in 1249
cycles: out 1304, in 1247

AMD 64 X2 4600 + / 2 gig memory - running the 32 bit version of
2.6.24-rc5-git1

>From /proc/cpuinfo

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 43
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
stepping        : 1
cpu MHz         : 2412.378
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm
3dnowext 3d
now pni lahf_lm cmp_legacy ts fid vid ttp
bogomips        : 4827.69
clflush size    : 64




^ permalink raw reply	[flat|nested] 68+ messages in thread

end of thread, other threads:[~2007-12-22 22:27 UTC | newest]

Thread overview: 68+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-12-11 23:31 [RFT] Port 0x80 I/O speed Rene Herman
2007-12-11 23:40 ` Maxim Levitsky
2007-12-11 23:44   ` Rene Herman
2007-12-12  0:14     ` Maxim Levitsky
2007-12-12  0:27       ` Rene Herman
2007-12-11 23:43 ` Alejandro Riveira Fernández
2007-12-11 23:51   ` Rene Herman
2007-12-12  0:09     ` Alejandro Riveira Fernández
2007-12-12  0:16       ` Rene Herman
2007-12-12 11:43         ` Alejandro Riveira Fernández
2007-12-12 21:02         ` H. Peter Anvin
     [not found]   ` <Pine.LNX.4.61.0712120753210.4443@chaos.analogic.com>
2007-12-12 13:20     ` Rene Herman
2007-12-12 13:23       ` linux-os (Dick Johnson)
2007-12-11 23:55 ` Nigel Cunningham
2007-12-12  0:01   ` Rene Herman
2007-12-12  2:07     ` Nigel Cunningham
2007-12-12  1:19 ` Alistair John Strachan
2007-12-12  1:28 ` Randy Dunlap
2007-12-12  1:40 ` Mike Lampard
2007-12-12  5:23 ` Kyle McMartin
2007-12-12  7:18   ` Rene Herman
2007-12-13  2:41     ` H. Peter Anvin
2007-12-12 19:25   ` H. Peter Anvin
2007-12-12 19:32     ` Andi Kleen
2007-12-12 19:43       ` H. Peter Anvin
2007-12-12  8:17 ` Paolo Ornati
2007-12-12  8:38   ` Edwin de Caluwé
2007-12-12  8:35 ` Dave Young
2007-12-12  8:48 ` Jiri Slaby
2007-12-12 11:25   ` Jiri Slaby
2007-12-12 15:50     ` Rene Herman
2007-12-12 15:53     ` Rene Herman
2007-12-12 18:44     ` H. Peter Anvin
2007-12-12 19:19       ` Rene Herman
2007-12-13 15:19         ` Jiri Slaby
2007-12-12  8:59 ` Juergen Beisert
2007-12-12 14:30   ` Rene Herman
2007-12-12 15:12     ` Juergen Beisert
2007-12-12  9:55 ` Luciano Rocha
2007-12-12  9:57 ` Romano Giannetti
2007-12-12 16:27   ` Rene Herman
2007-12-12 10:28 ` Peter Zijlstra
2007-12-12 10:34 ` Dave Haywood
2007-12-12 11:57 ` Ville Syrjälä
2007-12-13 16:42   ` Ville Syrjälä
2007-12-12 16:16 ` John Stoffel
2007-12-12 16:39 ` Olivér Pintér
2007-12-12 16:53 ` Ondrej Zary
2007-12-12 17:00   ` H. Peter Anvin
2007-12-12 16:59 ` Cyrill Gorcunov
2007-12-12 17:27 ` Török Edwin
2007-12-12 18:54   ` David P. Reed
2007-12-12 18:39 ` SL Baur
2007-12-12 19:06   ` Rene Herman
2007-12-12 21:32 ` Jesper Juhl
2007-12-12 23:54 ` Jan Engelhardt
2007-12-13  0:13   ` Jan Engelhardt
2007-12-13  2:06   ` H. Peter Anvin
2007-12-22 22:27 ` Bauke Jan Douma
2007-12-12  5:06 Chris Holvenstot
2007-12-12 11:20 linux
2007-12-12 12:35 ` Paolo Ornati
2007-12-12 14:48 ` Rene Herman
     [not found] <9zmRR-3pA-25@gated-at.bofh.it>
2007-12-13 16:27 ` James Kosin
2007-12-13 22:07   ` Rene Herman
2007-12-13 22:30     ` Jesper Juhl
2007-12-13 22:37       ` Rene Herman
     [not found] <9A0cz-7xy-13@gated-at.bofh.it>
     [not found] ` <9A0cz-7xy-11@gated-at.bofh.it>
     [not found]   ` <9A4pU-69z-15@gated-at.bofh.it>
2007-12-14 14:08     ` James Kosin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).