Tips on Re-configuring the kernel

[ndering 0]

A while back I recompiled my kernel for the first time to use ACPI for my laptop. But this kernel ran much much slower than the one that came with my distro! (redhat 9). Is there a good web site that has info on re configuring the kernel so it runs much faster? Because when i did make menuconfig i was pretty much guessing on alot of stuff about what i did and didn't need, and i want to make a kernel that runs much faster, than the distro kernel if possible. Thanks in advance for any advice!

[danleff 0]

It depends on what version of the kernel you are using. If it is 2.4.XX;

 

I liked the reference here.

 

If you can use make xconfig instead of make menuconfig, this will give you a box that explains what each module is. This can come in very handy in removing what you do not need.

 

I'm having a heck of a time with 2.6.0 on my system. The same site has an article on this version, if you need it. What's nice is that in this latest version, make gconfig is a slick interface and you skip doing make dep in the process.

 

Just do a google search "kernel how to" and you will also get a lot of hits.

 

The archives of this site for August have some good articles. On the 2.6.0 version it is titled "slackware on fire."

[ndering 0]

Ok, i have one more question. One thing i'm not clear on concerning kernel configuration is when to make something into a module and when to compile it directly into the kernel. If I understand correctly, it's a trade off between the amount of disk space that the kernel uses versus how fast it is. In other words, if I make a crapload of modules the kernel will take up less disk space, but will be much slower because of the runtime overhead that modules create through dynamic linking. Am I right or is this a bunch of crap?

[gvissers 0]

>Ok, i have one more question. One thing i'm not clear on concerning kernel configuration is when to make something into a module and when to compile it directly into >the kernel. If I understand correctly, it's a trade off between the amount of disk space that the kernel uses versus how fast it is. In other words, if I make a crapload of >modules the kernel will take up less disk space, but will be much slower because of the runtime overhead that modules create through dynamic linking. Am I right or is >this a bunch of crap?

 

Every module you install will also take up disk space, so that will not be the issue :-)

If you use modules, you can include them in your running kernel when you need them, thus

saving some memory by unloading modules you don't need. This will cause some overhead

when you load; not sure if it's slower once they're loaded. Plus, if you've compiled every

module that came with your kernel, you won't have to recompile your kernel if it doesn't

include what you need: you can just load the corresponding module.

 

If I were you, I'd compile everything you know you need into the kernel, and the rest as

modules. That way, you might gain a bit of speed at startup (because you need to load

less modules), and you have maximum flexibility. Unless you're really short on RAM or disk

spave, of course.

 

--- G

[danleff 0]

Good explanation!

 

One more thing. If you plan on making a boot floopy and have a rescue/boot floopy as a back-up boot device, then making more modules available reduces the kernel image size. If you compile too many hardware settings into the kernel image itself, then the image may be too big to fit on a floppy. So, it depends on what you are looking to do.

 

Of course, if you back-up your installation to a .gz file using partimage, you don't have to worry about this and you can compile as much hardware as you want directly into the kernel image.