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.
signature.asc
Description: This is a digitally signed message part
