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