Harold Norris wrote:
> Hi,
> 
> Its very true that you lose out on RedHat's support for a recompiled
> kernel, but if you maintain the latest version of the kernel, you should
> get the latest fixes, whatever they may be.

You don't automatically get Red Hat's security fixes. Red Hat employs 
several kernel folk including Alan Cox.

I would not be surprised if RH has support for new hardware before the 
standard kernel. It certainly did back when I built kernels. See my 
comments on the latest Fedora 8 kernel further on.

> 
> I personally have been using Redhat with my own kernel for about 10
> years or so (RedHat 5.2) and have never had a kernel related issue.  As
> far as performance goes, if you remove all of the unnecessary modules
> from the kernel, and build it to work with the hardware you have,  it
> will run faster because the available kernels are built to run on
> generic processors.  If you take a i386 kernel and run it on a Pentium
> 4, you lose out on all optimizations for the faster processor.
> 

I used to build my own kernels sometimes too. I built late 2.3.xx and 
2.4.0 kernels for USB support. I have built kernels as far back as late 
2.0 kernels.

there are two relevant gcc switches that affect the instructions chosen.
-march determines the instruction set. Choosing "-march=i586" limits the 
compiler to building for Pentium and later processors.
-mtune specifies the target processor. Code is optimised for this processor

On SL5 you might build a kernel with one of these -march specifications:
_k8, opteron, athlon64, athlon-fx_
           AMD K8 core based CPUs with x86-64 instruction set support.
           (This supersets MMX, SSE, SSE2, 3dNOW!, enhanced 3dNOW! and
           64-bit instruction set extensions.)
and similarly for -mtune.

For Intel processors one may choose:
     _nocona_
           Improved version of Intel Pentium4 CPU with 64-bit
           extensions, MMX, SSE, SSE2 and SSE3 instruction set support.

On Fedora, on 64-bit Intel, the latest Fedora kernel builds with these 
-m switches:
-m64
-maccumulate-outgoing-args
-mcmodel=kernel
-mno-3dnow
-mno-mmx
-mno-red-zone
-mno-sse
-mno-sse2
-mtune=generic

It might be that there's a better combination than that (it certainly 
looks suboptimal to me), if I build a replacement takes time, mine for 
configuring it, and then computer time. Building a smaller kernel takes 
more of my time, because I will take longer configuring it.

I am loathe to build a kernel sans modules, because Red Hat's scripts 
assume kernels structured they way Red Hat delivers them.

Also, I am sceptical that there's any significant performance benefit to 
built-in drivers. They have to be read from disk one way or the other, 
once they're modules are loaded they take much the same amount of RAM as 
the built-in drivers.


On my desktop, which is running SL5, I find that system (kernel) time 
runs to about ten percent of user time, the time spent doing my work. If 
I optimised all the kernel time away, I's still only have a system 
that's ten percent faster.

I don't think I will get anything like 100% reduction in system time, 
and I don't think that, for small numbers of systems. it's worth the 
trouble,

If I were building a significant cluster, and I'm sure some here do, 
then it may well be useful to build cut-down kernels. I'd also be 
looking to see how much code I could build with Intel's C compiler.

The Fedora 8 2.6.23.1 kernel (I'm eyeing the source rpm now, I don't 
have one for EL5) contains 138 patches covering things such as wireless 
(including the new driver for Atheros), USB, firewire. selinux, 
execshield, ata, sound.






-- 

Cheers
John

-- spambait
[log in to unmask]  [log in to unmask]
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

Please do not reply off-list