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