Recommendations on a fast Kernel??
 

Hi People!

I just started on my LFS-System and I'm pretty much down to where it comes to actually compiling the Kernel.

I compiled a custom Kernel from the sources of www.kernel.org on my SuSE once and it turned out to be terribly slow...

I am now thinking about compiling from the SuSE sources. Any other recommendations/ hints on how to get a fast Kernel?

Any patches I should have a look at?

Thanx all, Steave.

Well the kernel is really something you have to figure out yourself which components you need. There is no recipe for a fast kernel. Just try to read the descriptions of each component and then decide whether you need it or not. Compiling a lot of things as modules will often help. Especially things you only need once in a while. Usually if you haven't done it before and you don't know every piece of hardware in your computer it could take several compiles to get it right. But eventually it should at least be faster then a kernel which gets shipped along with those standard distributions.

OK, I'll do some reading...

Also: to everybody who knows something about gcc:

Which flags should I use to compile on my Athlon TB? I know about -O3 and -march=i686 other CFLAGS or stuff I could use, so my gcc will produce better code??

i'd recommend the mjc3 patch against the 2.4.17 standard kernel - it's the fastest kernel i've had for desktop purposes - it's got pretty much every performance patch out there on it. haven't crashed it yet, but it's probably not stable yet for heavy db or server use.

off the top of my head, i think it includes robert love's preemption patch, ingo's modular scheduler, and van riel's reverse mapping vm... it'd be interesting to see the aa vm with the patches.

If you want high optimization you could try some of the following:

-s
linker option which removes all symbol table and relocation information from the binary

-O3
sets the highest optimization level

-fomit-frame-pointer
tells the compiler not to keep the frame pointer in a register for functions that don't need one

-march=i686
defines the instructions set to use when compiling

-malign-functions=4
aligns the start of functions to a 2 raised to 4 byte boundary

-funroll-loops
performs the optimization of loop unrolling

-fexpensive-optimizations
performs a number of minor optimizations which are relatively expensive

-malign-double
controls whether gcc aligns some variables on a two word boundary or a one word boundary

-fschedule-insns2
similar to `-fschedule-insns', but requests an additional pass of instruction scheduling after register allocation has been done

-mwide-multiply
control whether GCC uses the mul and imul that produce 64-bit results in eax:edx from 32-bit operands to do long long multiplies and 32-bit division by constants

-ffast-math
compiles in faster floating point math routines

You could also try specifying athlon instead of i686 for the architecture. But if the software causes any problems then there is a great chance it's because of the optimizations.

I tried looking for the patches isajera mentioned but I couldn't really find them. Probably could find more if I looked in the kernel mailing archives. I found a linux kernel patches website though:
http://linux-patches.rock-projects.com

Thank you!

This really gets me further on the way!

I'll be around...
Steav.e

http://www.kernel.org/pub/linux/kern...-mjc3.patch.gz

there's a bunch of patches on the kernel.org ftp where some kernel hackers keep copies of their main patches or trees. i mentioned this one because it was patched together specifically for speed in the desktop enviroment.

I'm surprised no one voiced skepticism over the Suse kernel re-compile slowing down your machine. I mean technically it could, but that's usually one big error that keeps sucking down resources... like the SCSI card constantly probing for devices because the driver in the kernel tree is kazoo... but that even that stuff is pretty rare. Are you sure it wasn't SuSe acting funny because way too much of it is built against having a very specific set of kernel resources?

All of the resources that are eaten up these days go into the 70-80 processes that distros now have running by default. LFS starts with what? 9? As far as the kernel goes, pristine 2.4.17 source with no support for any hardware you don't have is going to be un-noticeably slower than a well patched kernel, especially in the case of something as ridiculously fast as a 1Ghz+ T-bird. All of the speed is going to go away depending on what packages you install next and how many things you end up with running in 'top'.

Sorry, my 2 cents. As far as special kernel patching goes, I recommend the NSA patch set, but that's just because I think security is fun to play with.

Luck,

Finegan