[Semi-OT] Dual Athlon support in kernel

[Semi-OT] Dual Athlon support in kernel

[Mike A. Harris]

Would the current state of athlon support be considered stable?
I've got a colleague interested in getting a dual athlon box, and
I'll be making the decision as to what hardware to purchase.  I'm
wondering is dual Athlon viable for a business solution right
now, or is it considered "experimental"?

What hardware would be recommended for a dual CPU system that
needs to be fairly rock solid?  Should I recommend to stay with
the P-III Xeon?  Or something else?  What issues would I expect
to have to deal with if going with a dual Athlon?

Also, what is a good rock solid SCSI RAID controller?  Money is
no object.  Reliability, performance and Linux compatibility are
though.

Chipsets to avoid?

Any experiences/info good/bad would be greatly appreciated.



----------------------------------------------------------------------
    Mike A. Harris  -  Linux advocate  -  Free Software advocate
          This message is copyright 2001, all rights reserved.
  Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------

Re: [Semi-OT] Dual Athlon support in kernel

[Andrea Arcangeli]

On Tue, Apr 24, 2001 at 01:22:15AM -0400, Mike A. Harris wrote:
> Would the current state of athlon support be considered stable?

yes.

Andrea

Re: [Semi-OT] Dual Athlon support in kernel

[Tom Leete]

"Mike A. Harris" wrote:
> 
> Would the current state of athlon support be considered stable?
> I've got a colleague interested in getting a dual athlon box, and
> I'll be making the decision as to what hardware to purchase.  I'm
> wondering is dual Athlon viable for a business solution right
> now, or is it considered "experimental"?
> 
> What hardware would be recommended for a dual CPU system that
> needs to be fairly rock solid?  Should I recommend to stay with
> the P-III Xeon?  Or something else?  What issues would I expect
> to have to deal with if going with a dual Athlon?
> 
> Also, what is a good rock solid SCSI RAID controller?  Money is
> no object.  Reliability, performance and Linux compatibility are
> though.
> 
> Chipsets to avoid?
> 
> Any experiences/info good/bad would be greatly appreciated.

The build problen with Athlon+SMP was solved by AA's patch. I had tested a
similar patch on UP over 2.4.0-test and previous 2.4 releases with nary a
problem.

This may be too experimental for your purposes, but FWIW I'm writing from a
2.4.4-pre3 built with gcc-2.97-20010205 using -march=athlon set by the k7
config. I've been building kernels with that snapshot since the middle of
Feb. With the current image, the box has locked up once in continuous use. I
can't say what caused that one, no log survived. 

Cheers,
Tom

-- 
The Daemons lurk and are dumb. -- Emerson

Re: [Semi-OT] Dual Athlon support in kernel

[Ville Herva]

On Tue, Apr 24, 2001 at 03:33:00AM -0400, you [Tom Leete] claimed:
>
> The build problen with Athlon+SMP was solved by AA's patch. I had tested a
> similar patch on UP over 2.4.0-test and previous 2.4 releases with nary a
> problem.
> 
> This may be too experimental for your purposes, but FWIW I'm writing from a
> 2.4.4-pre3 built with gcc-2.97-20010205 using -march=athlon set by the k7
> config. I've been building kernels with that snapshot since the middle of
> Feb. With the current image, the box has locked up once in continuous use. I
> can't say what caused that one, no log survived. 

There's also AthlonLinux http://athlonlinux.org/ and AthlonGCC
http://athlonlinux.org/agcc/about.shtml, but I have no experience with those
(I have no Athlon ;( ).


-- v --

v@iki.fi

Re: [Semi-OT] Dual Athlon support in kernel

[Joseph Carter]

[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]

On Tue, Apr 24, 2001 at 01:18:57PM +0300, Ville Herva wrote:
> There's also AthlonLinux http://athlonlinux.org/ and AthlonGCC
> http://athlonlinux.org/agcc/about.shtml, but I have no experience with those
> (I have no Athlon ;( ).

A warning about agcc, I've discovered that it does not always compile code
quite the way you expect it.  This is unsurprising given it's based on
pgcc which is known to change alignments on you in ways that sometimes
break things subtly.


I do not know if agcc actually can produce code which simply does not work
as is reported with pgcc (I suspect the alignment differences account for
many of those cases), but I recall reading in the past few days that agcc
is not supported for compiling the kernel.

It also fails to properly compile certain other programs, notably anything
that includes asm functions.  As a result, my own experience suggests you
consider agcc in the same class as gcc 3.0 at the moment - experimental.
Hopefully the k7 optimizations that work well will find their way into a
nice athlon subarch options in standard gcc and agcc won't be necessary.

-- 
Joseph Carter <knghtbrd@debian.org>                Free software developer

Guns don't kill people.  It's those damn bullets.  Guns just make them go
really really fast.
        -- Jake Johanson


[-- Attachment #2: Type: application/pgp-signature, Size: 273 bytes --]

Re: [Fully-OT] Dual Athlon support in kernel

[Ville Herva]

On Tue, Apr 24, 2001 at 03:39:22AM -0700, you [Joseph Carter] claimed:
> 
> A warning about agcc, I've discovered that it does not always compile code
> quite the way you expect it.  This is unsurprising given it's based on
> pgcc which is known to change alignments on you in ways that sometimes
> break things subtly.

While people always bash pgcc, I've had pretty good experiences with it.
Mostly everything I've compiled with it has worked quite well - even a
2.0.34 kernel (which I compiled accidentally with pgcc) ran with no problems
for long times. Sometimes pgcc does give internal errors with highest
optimizations, though. 

Don't take me wrong: I'm not advocating using pgcc for any serious
production systems (nevermind any kernel stuff), but perhaps it shouldn't be
completely discarded for perfomance hungry stuff (where a miscompile won't
cause third World War). It does gain as much as 30% in some cases over older
gcc - I'm not sure how good the newest gcc's are, but oldish pgcc does beat
gcc-2.96 on stuff I tried. (Didn't gcc get a new IA32 backend some time ago?
How good is that?)

> I do not know if agcc actually can produce code which simply does not work
> as is reported with pgcc (I suspect the alignment differences account for
> many of those cases), but I recall reading in the past few days that agcc
> is not supported for compiling the kernel.

Any pgcc variant is quite bad idea for kernel stuff. There are known
problems (I think), and it doesn't even gain that much since kernel is
pretty much hand optimized anyway.

But if the instruction scheduler in the compiler knows about K7, I imagine
that could gain something. Perhaps it could use the preload instructions etc
as well? The again, I'm no kernel NOR compiler guru.
 
> It also fails to properly compile certain other programs, notably anything
> that includes asm functions.  As a result, my own experience suggests you
> consider agcc in the same class as gcc 3.0 at the moment - experimental.
> Hopefully the k7 optimizations that work well will find their way into a
> nice athlon subarch options in standard gcc and agcc won't be necessary.

Hope so. Unfortunately AMD doesn't seem to be doing all that much compiler
work (Intel has a whole compiler suite for Win, and did the beginnings of
pgcc, if I've not mistaken.)


-- v --

v@iki.fi

Re: [Semi-OT] Dual Athlon support in kernel

[Andreas Jaeger]

Joseph Carter <knghtbrd@debian.org> writes:

> On Tue, Apr 24, 2001 at 01:18:57PM +0300, Ville Herva wrote:
> > There's also AthlonLinux http://athlonlinux.org/ and AthlonGCC
> > http://athlonlinux.org/agcc/about.shtml, but I have no experience with those
> > (I have no Athlon ;( ).
> 
> A warning about agcc, I've discovered that it does not always compile code
> quite the way you expect it.  This is unsurprising given it's based on
> pgcc which is known to change alignments on you in ways that sometimes
> break things subtly.
> 
> 
> I do not know if agcc actually can produce code which simply does not work
> as is reported with pgcc (I suspect the alignment differences account for
> many of those cases), but I recall reading in the past few days that agcc
> is not supported for compiling the kernel.
> 
> It also fails to properly compile certain other programs, notably anything
> that includes asm functions.  As a result, my own experience suggests you
> consider agcc in the same class as gcc 3.0 at the moment - experimental.
> Hopefully the k7 optimizations that work well will find their way into a
> nice athlon subarch options in standard gcc and agcc won't be necessary.

Note that gcc 3.0 will have support for Athlons, -mcpu=athlon and
-march=athlon are both supported and will do the right thing.  For
details you should ask Jan Hubicka who implemented this some time ago,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: [Semi-OT] Dual Athlon support in kernel

[Martin Clausen]

On Tue, Apr 24, 2001 at 01:22:15AM -0400, Mike A. Harris wrote:
> Also, what is a good rock solid SCSI RAID controller?  Money is
> no object.  Reliability, performance and Linux compatibility are
> though.

I have very good experiences with the Mylex controllers/drivers! 

But then again I also have good experiences with the new-style SW-RAID;
it performs very well indead and it is quite cheap :) 

Regards,
Martin

-- 
                       There's no place like ~

Re: [Semi-OT] Dual Athlon support in kernel

[Jakob Østergaard]

On Wed, Apr 25, 2001 at 01:18:42AM +0200, Martin Clausen wrote:
> On Tue, Apr 24, 2001 at 01:22:15AM -0400, Mike A. Harris wrote:
> > Also, what is a good rock solid SCSI RAID controller?  Money is
> > no object.  Reliability, performance and Linux compatibility are
> > though.
> 
> I have very good experiences with the Mylex controllers/drivers! 
> 
> But then again I also have good experiences with the new-style SW-RAID;
> it performs very well indead and it is quite cheap :) 

Remember, any RAID solution is based on software.  The difference is, whether
the software is closed-source and hiding on a slow processor, or free software
running on a much more powerful processor (which on the other hand also needs
to run other parts of the system, as this is the main CPU).

The main selling-points of software RAID except for stability and usually much
higher performance than "hardware" RAID is, that the interaction between the
userland tools and the RAID code is "open".   People who use RAID, be it one
kind or the other, occationally meet some problem where the RAID seems to be
having a will of it's own.  With the "open" solution, you as an administrator
actually have a chance of figuring out what happens.

I know the usual trouble-shooting on proprietary RAID seems to be "uh, it
doesn't work ?  well, try the newer drivers and firmware.  Oh, you did that,
well, then try the older versions then".   If people are comfortable with that
kind of systems, well, fine as long as it's not my data.   I want to know the
code I trust my data with.  From an theoretical point of view, it is stupid to
trust proprietary code - however, in the case of RAID I believe (at least some
of) the manufacturers has managed to prove that even from a purely pragmatic
point of view it is stupid to trust their code.

Yet, an awful lot of people seem to prefer the so-called "hardware" RAID  :)


-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............: