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