[CLUE-Tech] Athlon = i686 in kernel 2.4.7 Makefile

[Jed S. Baer]

On Sun, 24 Mar 2002 21:17:49 -0700
"Timothy C. Klein" <teece at silverklein.net> wrote:

> Oh yeah, you did say that.  For grins, I downloaded the 2.4.7 source
> tree, and looked at it.  That tree does have the line to use the Athlon
> arch if it is available.  The relevant lines ar 65-67 of:
> 
> linux/arch/i386/Makefile.

Must be nice to have bandwidth ;-). Interesting that. I'm assuming you
mean the "vanilla" 2.4.7?

> So, if it is in that source tree by default, why the heck would RedHat
> take it out?  That just baffles me.

Yeah, me too. Maybe because the knew they were including a development
branch gcc, and didn't want for it to break anything in the kernel?

> So now, I have an Athlon architecture kernel, rather than i686.  I
> downloaded lmbench, and ran a quick benchmark on both kernels.  I was
> rather surprised:  the Athlon one *is* actually faster at certain tasks.
> I would need to do several runs to know for sure, but it does seem to
> make a difference, especially for DISK->MEMORY->CPU bandwidth tests.
> Looks like about 1% to 10% increase on local communication bandwidths.
> 
> So, it might be worth the trouble downloading the latest kernel tarball.
> BTW, this kernel is patched for low-latency, and full-preemptability,
> but otherwise is just the default 2.4.18 kernel.

I've tended to stay away from bleeding-edge for my "day-to-day" box.
Which, BTW, for all practical purposes, is my "only" box. Although at this
point, that seems a rather silly statement, because clearly, installing a
release from RH doesn't mean there aren't any "not quite up to Debian
standards" packages. And from what little I've read about kernel updates,
there are benefits to getting a newer 2.4 kernel, although the extent to
which I'd notice them is debatable. I don't even come close to taxing my
Athlon 750. However, going back and rereading some of Bero's comments on
slashdot, and elsewhere (http://www.bero.org/gcc296.html) makes me feel
better, and having Alan Cox working for RedHat does too.

All of which leaves me with a quandary about whether 'tis better to better
to leave some decisions about the kernel, gcc, etc. in the hands of people
who deal with it for a living, and just be resolved to spending a day
fixing things whenever I do a distro upgrade, or start following more
mailing lists, and do (not sure what here).

jed

-- 
"Those who expect to reap the blessings of freedom must, like men,
 undergo the fatigue of supporting it."
 - Thomas Paine