Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops

On 11-12-07 16:37, Paul Rolland wrote:

Great, thanks for the quick replies.

That last one below especially is quite a bit more than 1. As said before, most hardware isn't in fact going to need anything but I suppose udelay(2) might be the "safer" replacement for the outb then...

On Tue, 11 Dec 2007 16:28:56 +0100
Rene Herman <rene.herman@xxxxxxxxxxxx> wrote:

On 11-12-07 15:15, Rene Herman wrote:

On 11-12-07 14:32, Paul Rolland wrote:

This might be a bit more constant, I suppose. This serialises with cpuid. Don't see a difference locally, but perhaps you do.
Well, yes, at least on the PIII and the Opteron... Core2 is still changing
a lot...

On a Duron 1300 with an actual ISA bus, "out" is between 1300 and 1600 for me and "in" between 1200 and 1500 with a few flukes above that which will I suppose be caused by the bus (ISA _or_ PCI) being momentarily busy or some such...

The results :

Core 2Duo 1.73 GHz :
[root@tux tmp]# ./in2
out: 2777
in : 2519
[root@tux tmp]# ./in2
out: 2440
in : 2391
[root@tux tmp]# ./in2
out: 2460
in : 2388

Okayish I guess, especially when subsequent runs stay near those values.

2500/1730 = 1.45 us

Pentium III :
[root@www-dev /tmp]# ./in2
out: 746
in : 747
[root@www-dev /tmp]# ./in2
out: 746
in : 747
[root@www-dev /tmp]# ./in2
out: 746
in : 745

746/600 ~= 1.24 us

AMD Opteron 150 :
-bash-3.1# ./in2
out: 4846
in : 4845
-bash-3.1# ./in2
out: 4846
in : 4846
-bash-3.1# ./in2
out: 4846
in : 4845

4846 / 2400 = 2.02 us

Rene.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: b44: regression in 2.6.22 (resend)
    ... if the PCI bus is truly faulty). ... So for most hardware, you see ... tmp = read ... and the method that determines no interrupt handling is needed. ...
    (Linux-Kernel)
  • Re: Thread safe
    ... will suffice since you're not releasing getLock in this case. ... T * tmp = queue0.pop; ... When you get hardware, you make software. ...
    (comp.programming.threads)
Quantcast