On Sun, 2011-03-13 at 17:07 +0000, Ben Hutchings wrote:
> On Sun, 2011-03-13 at 17:47 +0100, Cesare Leonardi wrote:
> > On 13/03/2011 04:45, Ben Hutchings wrote:
> > > This really ought to be checked on a Pentium M as well, though.
> >
> > Ok, my notebook uses a Pentium M 725 (Dothan).
>
> I think that one actually has PAE. /proc/cpuinfo will tell you for
> sure.
>
> > I've run the following script (it should be equivalent to yours) with
> > 2.6.38-rc7 from experimental in recovery mode, both for 486 and 686.
> > Attached you can find the results.
> >
> > #!/bin/bash
> > for i in {1..3}; do
> > netperf -H 192.168.10.1,4 -t TCP_STREAM -l 60
> > netperf -H 192.168.10.1,4 -t UDP_RR -l 60
> > done
> >
> > The differences between 486 and 686 look very small, if not null.
> > If you want me to do some more tests, i'm available.
>
> You seem to have tested the loopback device - which has quite different
> performance from real networking!
>
> Actually my previous (not completely working) laptop has some kind of
> Pentium M so I could do this testing myself.
Done. That laptop is a Thinkpad T42 with a Pentium M model 745, which
does not have PAE.
I turned off interrupt moderation for the UDP_RR tests (so far as
ethtool says; personally I can't believe the transaction rate can be so
low with moderation completely off, but then I'm spoiled).
With the 686 flavour:
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.250 (192.168.2.250) port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 60.04 751.58
87380 16384 16384 60.03 751.20
87380 16384 16384 60.04 751.42
UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.250 (192.168.2.250) port 0 AF_INET : demo
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
126976 126976 1 1 60.00 9774.93
114688 114688
126976 126976 1 1 60.00 9856.57
114688 114688
126976 126976 1 1 60.00 9840.54
114688 114688
With the 486 flavour:
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.250 (192.168.2.250) port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 60.03 751.29
87380 16384 16384 60.03 751.08
87380 16384 16384 60.03 751.22
UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.250 (192.168.2.250) port 0 AF_INET : demo
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
126976 126976 1 1 60.00 9846.26
114688 114688
126976 126976 1 1 60.00 9854.01
114688 114688
126976 126976 1 1 60.00 9867.24
114688 114688
Looks very marginally slower on the TCP_STREAM test, but all the results
for that are so close together that I suspect that the PCI bus on the
T42 is the bottleneck. (The other side of these tests is a T61 whose
Ethernet adapter is attached with PCI Express, so it should not be a
bottleneck.)
All in all, I'm convinced that using the current '486' configuration for
all PAE-incapable systems is unlikely to hurt their performance and will
generally improve it slightly.
As for the PAE-capable systems currently not using PAE, there is a cost:
approximately twice as much RAM needed for page tables, and twice as
much memory traffic required to read and write them in batches. But I
doubt it's significant. As benefits, we get more systems using the
NX/XD bit and fewer with RAM above 4 GB accidentally disabled.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part