Re: Dropping 686 non-pae kernel
On Sun, 2011-03-13 at 17:13 +, Ben Hutchings wrote: On Sun, 2011-03-13 at 09:18 +0100, Bastian Blank wrote: On Sun, Mar 13, 2011 at 03:57:56AM +, Ben Hutchings wrote: On Mon, 2011-02-14 at 11:34 +, 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. 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. 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
Re: Dropping 686 non-pae kernel
On Sun, Mar 13, 2011 at 03:57:56AM +, Ben Hutchings wrote: On Mon, 2011-02-14 at 11:34 +, 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-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110313081831.gb19...@wavehammer.waldi.eu.org
Re: Dropping 686 non-pae kernel
On Sun, Mar 13, 2011 at 09:18:31AM +0100, Bastian Blank wrote: On Sun, Mar 13, 2011 at 03:57:56AM +, Ben Hutchings wrote: On Mon, 2011-02-14 at 11:34 +, 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. signature.asc Description: Digital signature
Re: Dropping 686 non-pae kernel
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'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.
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.10.1
(192.168.10.1) port 0 AF_INET : demo
Recv SendSend
Socket Socket Message Elapsed
Size SizeSize Time Throughput
bytes bytes bytessecs.10^6bits/sec
87380 16384 1638460.003499.79
87380 16384 1638460.003534.46
87380 16384 1638460.003495.89
UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.10.1
(192.168.10.1) port 0 AF_INET : demo
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size SizeTime Rate
bytes Bytes bytesbytes secs.per sec
114688 114688 11 60.0064590.18
114688 114688
114688 114688 11 60.0064958.24
114688 114688
114688 114688 11 60.0064770.58
114688 114688
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.10.1
(192.168.10.1) port 0 AF_INET : demo
Recv SendSend
Socket Socket Message Elapsed
Size SizeSize Time Throughput
bytes bytes bytessecs.10^6bits/sec
87380 16384 1638460.003443.95
87380 16384 1638460.003450.00
87380 16384 1638460.003397.42
UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.10.1
(192.168.10.1) port 0 AF_INET : demo
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size SizeTime Rate
bytes Bytes bytesbytes secs.per sec
114688 114688 11 60.0060308.29
114688 114688
114688 114688 11 60.0060628.59
114688 114688
114688 114688 11 60.0060599.16
114688 114688
Re: Dropping 686 non-pae kernel
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.
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.
--
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
Re: Dropping 686 non-pae kernel
On Sun, 2011-03-13 at 09:18 +0100, Bastian Blank wrote: On Sun, Mar 13, 2011 at 03:57:56AM +, Ben Hutchings wrote: On Mon, 2011-02-14 at 11:34 +, 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? 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
Re: Dropping 686 non-pae kernel
On 13/03/2011 18:07, Ben Hutchings wrote: 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-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d7d0011.1010...@gmail.com
Re: Dropping 686 non-pae kernel
On 13/03/2011 18:07, Ben Hutchings wrote: 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. 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. x ministat-486.mod.txt + ministat-686.mod.txt ++ | +| |x +| |x +| |x +| |x +| |x +| |x +| |x +| |x +| | x x +| | x x +| | x x x + + | | x x x x + + + | | x x x x + + + | | x x x x + + + | | x * x x + + + | | x * x x + + + | | x * x * + + + | | x * x * + + + | | x * * * + + + | | x x * * * * + + | |x x x * * * * + + | |x x * * * * * + + | |x x * * * * * + + +| |x x * * * * * * + +| |x x * * * * * * * + +| |* * * * * * * * * + +| ||A__M_| | | |__A_M| | ++ N Min MaxMedian AvgStddev x 100 0.2 0.28 0.240.2349 0.018062462 + 101 0.2 0.3 0.260.25752475 0.021043096 Difference at 95.0% confidence 0.0226248 +/- 0.00542407 9.63165% +/- 2.3091% (Student's t, pooled s = 0.019617)
Re: Dropping 686 non-pae kernel
On Sun, 2011-03-13 at 17:07 +, 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 SendSend
Socket Socket Message Elapsed
Size SizeSize Time Throughput
bytes bytes bytessecs.10^6bits/sec
87380 16384 1638460.04 751.58
87380 16384 1638460.03 751.20
87380 16384 1638460.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 SizeTime Rate
bytes Bytes bytesbytes secs.per sec
126976 126976 11 60.009774.93
114688 114688
126976 126976 11 60.009856.57
114688 114688
126976 126976 11 60.009840.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 SendSend
Socket Socket Message Elapsed
Size SizeSize Time Throughput
bytes bytes bytessecs.10^6bits/sec
87380 16384 1638460.03 751.29
87380 16384 1638460.03 751.08
87380 16384 1638460.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 SizeTime Rate
bytes Bytes bytesbytes secs.per sec
126976 126976 11 60.009846.26
114688 114688
126976 126976 11 60.009854.01
114688 114688
126976 126976 11 60.009867.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
Re: Dropping 686 non-pae kernel
On Sun, 2011-02-27 at 05:09 +, Ben Hutchings wrote: [...] 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. 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 SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 87380 16384 1638460.03 325.73 87380 16384 1638460.03 326.83 87380 16384 1638460.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 SizeTime Rate bytes Bytes bytesbytes secs.per sec 126976 126976 11 60.005002.73 114688 114688 126976 126976 11 60.005024.31 114688 114688 126976 126976 11 60.005016.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 SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 87380 16384 1638460.02 350.12 87380 16384 1638460.02 349.91 87380 16384 1638460.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 SizeTime Rate bytes Bytes bytesbytes secs.per sec 126976 126976 11 60.005339.43 114688 114688 126976 126976 11 60.005389.63 114688 114688 126976 126976 11 60.005417.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. -- 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
Re: Dropping 686 non-pae kernel
On Mon, 2011-02-14 at 11:34 +, 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 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. 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
Re: Dropping 686 non-pae kernel
On Mon, 2011-02-14 at 11:34 +, Ben Hutchings wrote: 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 MaxMedian AvgStddev x 100 0.27 0.38 0.320.3192 0.021304905 + 100 0.28 0.4 0.34 0.3360.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. -- 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
Re: Dropping 686 non-pae kernel
On Mon, Feb 14, 2011 at 11:34:51AM +, Ben Hutchings wrote: Should we consider also 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-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110215141243.ga7...@wavehammer.waldi.eu.org
Dropping 686 non-pae kernel
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. 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 signature.asc Description: Digital signature
Re: Dropping 686 non-pae kernel
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? 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. signature.asc Description: This is a digitally signed message part
Re: Dropping 686 non-pae kernel
On Mon, Feb 14, 2011 at 11:34:51AM +, Ben Hutchings wrote: 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-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110214121102.ga11...@wavehammer.waldi.eu.org
Re: Dropping 686 non-pae kernel
On Monday 14 February 2011, Ben Hutchings wrote: 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. 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). 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-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201102141305.33593.david.goodeno...@btconnect.com
Re: Dropping 686 non-pae kernel
On Mon, Feb 14, 2011 at 01:05:33PM +, 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. 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-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011021418.ga13...@wavehammer.waldi.eu.org
Re: Dropping 686 non-pae kernel
On Mon, Feb 14, 2011 at 01:11:02PM +0100, Bastian Blank wrote: On Mon, Feb 14, 2011 at 11:34:51AM +, 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-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110214143506.gc28...@decadent.org.uk
Re: Dropping 686 non-pae kernel
On Mon, Feb 14, 2011 at 02:33:38PM +0100, Bastian Blank wrote: On Mon, Feb 14, 2011 at 01:05:33PM +, 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-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110214143719.gd28...@decadent.org.uk
Re: Dropping 686 non-pae kernel
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. :-( 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-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d59b765.3090...@gmail.com
Re: Dropping 686 non-pae kernel
On Tue, 2011-02-15 at 00:14 +0100, Cesare Leonardi wrote: 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. 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
