Dropping 686 non-pae kernel
Bastian Blank
I'd like to drop the i686 non-pae kernel. Currently we have sometimes
-686 with PAE; only the normal kernel is without PAE. I'd like to get
rid of this problem. Also this enables the use of the NX bit if supported
by the CPU.
There are some i686 processors without PAE support. This are some of the
Pentium M (all of the Banias line and some of the Dothan line) and the
Via C3 Nehemiah. All of them are released 2005 and earlier.
There are several possibilities to do this:
* Change name of meta-package:
- Breaks nothing
- Needs manual intervention by anyone using it
* Don't change the name:
- Breaks some systems
- No manual intervention by the rest
Bastian
--
Earth -- mother of the most beautiful women in the universe.
-- Apollo, "Who Mourns for Adonais?" stardate 3468.1
Ben Hutchings
> Hi folks
>
> I'd like to drop the i686 non-pae kernel. Currently we have sometimes
> -686 with PAE; only the normal kernel is without PAE. I'd like to get
> rid of this problem. Also this enables the use of the NX bit if supported
> by the CPU.
>
> There are some i686 processors without PAE support. This are some of the
> Pentium M (all of the Banias line and some of the Dothan line) and the
> Via C3 Nehemiah. All of them are released 2005 and earlier.
Also Geode LX.
Are there any changes we could/should make to the 486 flavour that would
make it perform better on 686-class processors? Should we consider also
dropping 486 support and making it a 586 flavour with corresponding
optimisations?
> There are several possibilities to do this:
> * Change name of meta-package:
> - Breaks nothing
> - Needs manual intervention by anyone using it
> * Don't change the name:
> - Breaks some systems
> - No manual intervention by the rest
Rename 686-bigmem to 686. Keep the 686-bigmem metapackage as a dummy
package depending on the 686 metapackage (for one release). When the
686 metapackage is upgraded on a system that doesn't support PAE,
display a warning with debconf.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
Bastian Blank
> On Mon, 2011-02-14 at 11:23 +0100, Bastian Blank wrote:
> > There are some i686 processors without PAE support. This are some of the
> > Pentium M (all of the Banias line and some of the Dothan line) and the
> > Via C3 Nehemiah. All of them are released 2005 and earlier.
> Also Geode LX.
Ah, yes.
> Are there any changes we could/should make to the 486 flavour that would
> make it perform better on 686-class processors? Should we consider also
> dropping 486 support and making it a 586 flavour with corresponding
> optimisations?
The 486 flavour have only 8% of the usage of the 686 and steadily
dropping. Which CPU types would be affected?
> Rename 686-bigmem to 686. Keep the 686-bigmem metapackage as a dummy
> package depending on the 686 metapackage (for one release). When the
> 686 metapackage is upgraded on a system that doesn't support PAE,
> display a warning with debconf.
Okay.
Bastian
--
"... freedom ... is a worship word..."
"It is our worship word too."
-- Cloud William and Kirk, "The Omega Glory", stardate unknown
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110214121...@wavehammer.waldi.eu.org
David Goodenough
> On Mon, 2011-02-14 at 11:23 +0100, Bastian Blank wrote:
> > Hi folks
> >
> > I'd like to drop the i686 non-pae kernel. Currently we have sometimes
> > -686 with PAE; only the normal kernel is without PAE. I'd like to get
> > rid of this problem. Also this enables the use of the NX bit if supported
> > by the CPU.
> >
> > There are some i686 processors without PAE support. This are some of the
> > Pentium M (all of the Banias line and some of the Dothan line) and the
> > Via C3 Nehemiah. All of them are released 2005 and earlier.
>
> Also Geode LX.
of little embedded boards. I am not sure these will run with -586 (but I may
be wrong).
There are many embedded boards with Geode SC1100 boards out there as well,
PCEngines WRAP boards, and one of the Microtik boards. The Geode LX appears
in places like the PCEngines Alix boards which are very much still
current. Although some of these are are no longer manufacturered
they are still in the field. I have some 8 year old boards still doing
sterling service, and I would not like to be blocked from using current
software. In fact I have just upgrade one (an old Wrap card) to Squeeze
because it was easier to do that and then install the extra package I needed
that to search through the archives looking for old copied of the package
that were current at the time I build the system image.
David
>
> Are there any changes we could/should make to the 486 flavour that would
> make it perform better on 686-class processors? Should we consider also
> dropping 486 support and making it a 586 flavour with corresponding
> optimisations?
>
> > There are several possibilities to do this:
> >
> > * Change name of meta-package:
> > - Breaks nothing
> > - Needs manual intervention by anyone using it
> >
> > * Don't change the name:
> > - Breaks some systems
> > - No manual intervention by the rest
>
> Rename 686-bigmem to 686. Keep the 686-bigmem metapackage as a dummy
> package depending on the 686 metapackage (for one release). When the
> 686 metapackage is upgraded on a system that doesn't support PAE,
> display a warning with debconf.
>
> Ben.
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201102141305.3359...@btconnect.com
Bastian Blank
> There are also the Vortex86SX based boards which are showing up in a variety
> of little embedded boards. I am not sure these will run with -586 (but I may
> be wrong).
The website does not tell anything about supported instruction set.
Rumors tells me, that is is in fact a plain 486 instruction set.
> There are many embedded boards with Geode SC1100 boards out there as well,
> PCEngines WRAP boards, and one of the Microtik boards. The Geode LX appears
> in places like the PCEngines Alix boards which are very much still
> current.
The Geode LX only fails the PAE constraint. In theorie it should run fine with
a 586-kernel.
Bastian
--
Yes, it is written. Good shall always destroy evil.
-- Sirah the Yang, "The Omega Glory", stardate unknown
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110214133...@wavehammer.waldi.eu.org
Ben Hutchings
> On Mon, Feb 14, 2011 at 01:05:33PM +0000, David Goodenough wrote:
> > There are also the Vortex86SX based boards which are showing up in a variety
> > of little embedded boards. I am not sure these will run with -586 (but I may
> > be wrong).
>
> The website does not tell anything about supported instruction set.
> Rumors tells me, that is is in fact a plain 486 instruction set.
The Wikipedia article describes it as 586-class except for the lack
of FPU.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110214143...@decadent.org.uk
Ben Hutchings
> On Mon, Feb 14, 2011 at 11:34:51AM +0000, Ben Hutchings wrote:
> > Are there any changes we could/should make to the 486 flavour that would
> > make it perform better on 686-class processors? Should we consider also
> > dropping 486 support and making it a 586 flavour with corresponding
> > optimisations?
>
> The 486 flavour have only 8% of the usage of the 686 and steadily
> dropping. Which CPU types would be affected?
According to the Kconfig help, anything called 486 plus UMC U5D and U5S.
According to Wikipedia, the Cyrix 5x86, 6x86 and MediaGX and the
NatSemi/AMD Geode GX1 and SC1100 processors also use a 486-class core.
Kconfig has an option for GX1 which is the same as 486 modulo some bug
workarounds.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110214143...@decadent.org.uk
Cesare Leonardi
>> Are there any changes we could/should make to the 486 flavour that would
>> make it perform better on 686-class processors? Should we consider also
>> dropping 486 support and making it a 586 flavour with corresponding
>> optimisations?
>
> The 486 flavour have only 8% of the usage of the 686 and steadily
> dropping. Which CPU types would be affected?
Yes, but if you decide to drop the 686-non-pae flavour, you should
expect 486 raising. For example my notebook use a Pentium M Dothan
without pae support. :-(
But please, don't raise too much the system request of the basic 486
kernel: Debian's kernel is one of the few that i can run on very old
cpus. For example i've many K6-2 cpu that cannot run many live-CDs
because they need cmov support. Debian-live works good.
Switching from 486 to 586 i see the risk to cut out old hardware that is
still able to use Debian.
Ciao.
Cesare.
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ben Hutchings
> On 14/02/2011 13:11, Bastian Blank wrote:
> >> Are there any changes we could/should make to the 486 flavour that would
> >> make it perform better on 686-class processors? Should we consider also
> >> dropping 486 support and making it a 586 flavour with corresponding
> >> optimisations?
> >
> > The 486 flavour have only 8% of the usage of the 686 and steadily
> > dropping. Which CPU types would be affected?
>
> Yes, but if you decide to drop the 686-non-pae flavour, you should
> expect 486 raising. For example my notebook use a Pentium M Dothan
> without pae support. :-(
Yes, that's what we expect.
> But please, don't raise too much the system request of the basic 486
> kernel: Debian's kernel is one of the few that i can run on very old
> cpus. For example i've many K6-2 cpu that cannot run many live-CDs
> because they need cmov support. Debian-live works good.
> Switching from 486 to 586 i see the risk to cut out old hardware that is
> still able to use Debian.
K6-2 is 586-class, so no problem for you. And of course some old PC
hardware would no longer be usable - just like the Alpha and PA-RISC
systems we dropped support for in squeeze.
Bastian Blank
> dropping 486 support and making it a 586 flavour with corresponding
> optimisations?
I think we need to discuss that with -toolchain and -release.
Bastian
--
Klingon phaser attack from front!!!!!
100% Damage to life support!!!!
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011021514...@wavehammer.waldi.eu.org
Ben Hutchings
> On Mon, 2011-02-14 at 11:23 +0100, Bastian Blank wrote:
> > Hi folks
> >
> > I'd like to drop the i686 non-pae kernel. Currently we have sometimes
> > -686 with PAE; only the normal kernel is without PAE. I'd like to get
> > rid of this problem. Also this enables the use of the NX bit if supported
> > by the CPU.
> >
> > There are some i686 processors without PAE support. This are some of the
> > Pentium M (all of the Banias line and some of the Dothan line) and the
> > Via C3 Nehemiah. All of them are released 2005 and earlier.
>
> Also Geode LX.
>
> Are there any changes we could/should make to the 486 flavour that would
> make it perform better on 686-class processors? Should we consider also
> dropping 486 support and making it a 586 flavour with corresponding
> optimisations?
Before we make a change, I wanted to do a little testing to see whether
running the 486 flavour is likely to hurt performance on the 686-class
processors without PAE. And I do mean a little testing - I don't want
to spend time constructing complex benchmarks.
On my home server, which has one of the affected processors,
specifically a VIA C3 "Nehemiah", I ran a simple benchmark for
filesystem access:
for i in $(seq 0 100); do \time find /usr >/dev/null; done
and took the 'system' times from all but the first iteration (i.e. only
the cache-hot case).
I then compared these data sets with 'ministat':
x 486
+ 686
+------------------------------------------------------------------------------+
| x + |
| x + + |
| x + + |
| x + + + |
| x + * + |
| x x x + * + |
| x x x + * + |
| x * x x + * + + |
| x * x * + * + + |
| x * * * + * + + |
| x * * * * * + + + |
| x * * * * * + * + |
| x * * * * * + * + |
| x * * * * * * * + + |
| x x * * * * * * * + + |
| * * * * * * * * * + + |
|x * * * * * * * * * + * +|
| |___________AM___________| |
| |______________A_M____________| |
+------------------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 100 0.27 0.38 0.32 0.3192 0.021304905
+ 100 0.28 0.4 0.34 0.336 0.02502524
Difference at 95.0% confidence
0.0168 +/- 0.0064417
5.26316% +/- 2.01808%
(Student's t, pooled s = 0.0232396)
For this limited test, the 486 kernel actually seems to be slightly
faster. Note that this was *not* run on an idle system, so other
activity could affect the measurements a little.
The Pentium M processors are likely to have different performance
characteristics so I would like to see someone test them as well.
It might be worth doing some kind of networking benchmark too.
Ben Hutchings
[...]
> faster. Note that this was *not* run on an idle system, so other
> activity could affect the measurements a little.
>
> The Pentium M processors are likely to have different performance
> characteristics so I would like to see someone test them as well.
>
> It might be worth doing some kind of networking benchmark too.
I ran some basic tests with netperf, connecting my reasonably fast
laptop to the system under test with 1000BASE-T and stopping all other
network traffic. I left the firewall rules in place.
3 iterations each of TCP_STREAM and UDP_RR on the 686 flavour:
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.1 (192.168.2.1) 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 325.73
87380 16384 16384 60.03 326.83
87380 16384 16384 60.02 323.85
UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.1 (192.168.2.1) 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 5002.73
114688 114688
126976 126976 1 1 60.00 5024.31
114688 114688
126976 126976 1 1 60.00 5016.31
114688 114688
and again with the 486 flavour:
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.1 (192.168.2.1) 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.02 350.12
87380 16384 16384 60.02 349.91
87380 16384 16384 60.02 350.70
UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.1 (192.168.2.1) 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 5339.43
114688 114688
126976 126976 1 1 60.00 5389.63
114688 114688
126976 126976 1 1 60.00 5417.86
114688 114688
Again, we see a performance benefit from the 486 flavour. My guess is
that the loss of 686 optimisations using e.g. the 'cmov' instruction is
outweighed by the removal of SMP locking overhead. SMP-alternatives
don't remove all the overhead on UP systems, and in particular the code
size will be larger with SMP-alternatives than with SMP disabled
altogether.
This really ought to be checked on a Pentium M as well, though.
Ben Hutchings
> > There are several possibilities to do this:
> > * Change name of meta-package:
> > - Breaks nothing
> > - Needs manual intervention by anyone using it
> > * Don't change the name:
> > - Breaks some systems
> > - No manual intervention by the rest
>
> Rename 686-bigmem to 686. Keep the 686-bigmem metapackage as a dummy
> package depending on the 686 metapackage (for one release). When the
> 686 metapackage is upgraded on a system that doesn't support PAE,
> display a warning with debconf.
I'm wavering on this. I don't like the idea of simply renaming
'686-bigmem' to '686', given there are a fair number of 686-class
systems without PAE, and I don't think users with a Pentium M are going
to expect that '486' is the right choice.
The distinctions between these two flavours will be:
1. One processor (min 486) with 386 page tables (currently '486')
2. One or more processors with PAE page tables (currently '686-bigmem')
How about naming them 'up' and 'smp-pae'? It'll be a pain to transition
the metapackages, but then we should never have to go through this again
when raising the minimum processor requirement.
Bastian Blank
> On Mon, 2011-02-14 at 11:34 +0000, Ben Hutchings wrote:
> > On Mon, 2011-02-14 at 11:23 +0100, Bastian Blank wrote:
> [...]
> > > There are several possibilities to do this:
> > > * Change name of meta-package:
> > > - Breaks nothing
> > > - Needs manual intervention by anyone using it
> > > * Don't change the name:
> > > - Breaks some systems
> > > - No manual intervention by the rest
> I'm wavering on this. I don't like the idea of simply renaming
> '686-bigmem' to '686', given there are a fair number of 686-class
> systems without PAE, and I don't think users with a Pentium M are going
> to expect that '486' is the right choice.
Please read again what I wrote.
> The distinctions between these two flavours will be:
> 1. One processor (min 486) with 386 page tables (currently '486')
> 2. One or more processors with PAE page tables (currently '686-bigmem')
Will not hold forever and you need to integrate the other architectures
into it.
> How about naming them 'up' and 'smp-pae'? It'll be a pain to transition
> the metapackages, but then we should never have to go through this again
> when raising the minimum processor requirement.
No, this will not help. See above.
Bastian
--
There are certain things men must do to remain men.
-- Kirk, "The Ultimate Computer", stardate 4929.4
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110313081...@wavehammer.waldi.eu.org
Geert Stappers
> On Sun, Mar 13, 2011 at 03:57:56AM +0000, Ben Hutchings wrote:
> > On Mon, 2011-02-14 at 11:34 +0000, Ben Hutchings wrote:
> > > On Mon, 2011-02-14 at 11:23 +0100, Bastian Blank wrote:
> > [...]
> > > > There are several possibilities to do this:
> > > > * Change name of meta-package:
> > > > - Breaks nothing
> > > > - Needs manual intervention by anyone using it
> > > > * Don't change the name:
> > > > - Breaks some systems
> > > > - No manual intervention by the rest
>
> > I'm wavering on this. I don't like the idea of simply renaming
> > '686-bigmem' to '686', given there are a fair number of 686-class
> > systems without PAE, and I don't think users with a Pentium M are going
> > to expect that '486' is the right choice.
>
> Please read again what I wrote.
Please provide 'where' and 'when'.
> > The distinctions between these two flavours will be:
> > 1. One processor (min 486) with 386 page tables (currently '486')
> > 2. One or more processors with PAE page tables (currently '686-bigmem')
>
> Will not hold forever and you need to integrate the other architectures
> into it.
>
> > How about naming them 'up' and 'smp-pae'? It'll be a pain to transition
> > the metapackages, but then we should never have to go through this again
> > when raising the minimum processor requirement.
>
> No, this will not help. See above.
>
> Bastian
>
> --
> There are certain things men must do to remain men.
> -- Kirk, "The Ultimate Computer", stardate 4929.4
>
A good thing to remain human,
is willing to communicate with humans.
Take time to explain why something is a good thing.
Take even more time to explain why something is a bad thing.
If the other side doesn't get the message,
both sides should allow each other the freedom to do their thing.
Groeten
Geert Stappers
--
> And is there a policy on top-posting vs. bottom-posting?
Yes.
Cesare Leonardi
> This really ought to be checked on a Pentium M as well, though.
Ok, my notebook uses a Pentium M 725 (Dothan).
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.
I've seen in the beginning of this thread you've reported the result of
a scripts elaborated by a program called ministat. I admit i've not
understood well neither the results nor the procedure. If you want me to
do that as well, please, explain a bit more the procedure.
Otherwise we can try to use some benchmark tools (no experience in this
field). I've seen that Phoronix is in Debian since few days.
Ciao.
Cesare.
Ben Hutchings
> 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.
> I've seen in the beginning of this thread you've reported the result of
> a scripts elaborated by a program called ministat. I admit i've not
> understood well neither the results nor the procedure. If you want me to
> do that as well, please, explain a bit more the procedure.
> Otherwise we can try to use some benchmark tools (no experience in this
> field). I've seen that Phoronix is in Debian since few days.
Put two sets of benchmark results in two files (one number per line).
ministat then calculates statistical measures of each set and a
comparison of the two sets.
Ben Hutchings
> On Sun, Mar 13, 2011 at 03:57:56AM +0000, Ben Hutchings wrote:
> > On Mon, 2011-02-14 at 11:34 +0000, Ben Hutchings wrote:
> > > On Mon, 2011-02-14 at 11:23 +0100, Bastian Blank wrote:
> > [...]
> > > > There are several possibilities to do this:
> > > > * Change name of meta-package:
> > > > - Breaks nothing
> > > > - Needs manual intervention by anyone using it
> > > > * Don't change the name:
> > > > - Breaks some systems
> > > > - No manual intervention by the rest
>
> > I'm wavering on this. I don't like the idea of simply renaming
> > '686-bigmem' to '686', given there are a fair number of 686-class
> > systems without PAE, and I don't think users with a Pentium M are going
> > to expect that '486' is the right choice.
>
> Please read again what I wrote.
The fact that changing the metapackage name is disruptive? Ever heard
of transitional packages?
> > The distinctions between these two flavours will be:
> > 1. One processor (min 486) with 386 page tables (currently '486')
> > 2. One or more processors with PAE page tables (currently '686-bigmem')
>
> Will not hold forever and you need to integrate the other architectures
> into it.
[...]
I would expect the minimum processor for (1) to increase over time
(hence my suggested name change), but other than that, what would need
to change? Major new x86 features seem to be restricted to Long Mode
only now.
Why do other architectures matter to this?
Cesare Leonardi
> I think that one actually has PAE. /proc/cpuinfo will tell you for
> sure.
Unfortunately not.
flags: fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov clflush dts
acpi mmx fxsr sse sse2 ss tm pbe up bts est tm2
In the past i read that there are different Dothan revisions: older have
PAE disabled in hardware, like mine. :-(
> You seem to have tested the loopback device - which has quite different
> performance from real networking!
Yes, silly me. At home i've no network to test, only my ADSL modem, and
hoped that using loopback some differences could be seen. But i've
forgotten to write that important detail, sorry.
> Put two sets of benchmark results in two files (one number per line).
> ministat then calculates statistical measures of each set and a
> comparison of the two sets.
Ok, will do, thank you.
Cesare.
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Cesare Leonardi
> ministat then calculates statistical measures of each set and a
> comparison of the two sets.
I've run the following in recovery mode (to avoid interference from
other programs/daemons):
for i in $(seq 0 100); do \time find /usr >/dev/null; done
Every results is composed by two line: i kept only the lines containing
user and system time. Then discarded the first line to keep only data
from cache. Then extrated only the columns containing system time.
The two file (1 for 486, 1 for 686) were passed to ministat, which
produced the attached file.
Ciao.
Cesare.
Ben Hutchings
> 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 Hutchings
Alternately we could go for the less disruptive renaming of '686-bigmem'
to '686-pae', and defer renaming of '486' until we actually bump the
processor requirement. This would also give us flavour names that
closely mirror those found in other distributions.