[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dropping 686 non-pae kernel



On Mon, 2011-02-14 at 11:34 +0000, 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           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.

-- 
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


Reply to: