Hi,
I guess I didn't explain the module "thing" properly. I too use
modules, but I eliminate the modules for hardware I don't have in my
system and fully customize the kernel for what I plan on using the
system for as opposed to turning on all standard modules.
Harold
John Summerfield wrote:
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.
