With a custom kernel I managed to reduce the kernel image size by 50%, but bootup time wasn't faster than with the stock kernel except by a few seconds only. At 35 seconds from hitting enter in grub to a login screen on a 4 year-old laptop, I can't really complain Probably editing init scripts would help more in that respect..

-A

Some day I will build one of those tickless low latency beasts just out of curiosity =]

I love tickling low latency beasts!

Surely there's no reason not to. In most linux distributions and even FreeBSD, there are some caveats to using to a custom kernel over a stock one, but Slackware was more or less tailored to trim down and customize your system the way you want.

I also recompiled my kernel to 2.6.31.1 , removed all the crap I didn't need.

- efficiency
- less problems that "could" arise
- bootup is a lot faster (I only have the modules I need)
- less prone to exploits vs a kernel that has everything included.

...

I usually enable tickless anyway, but latency does not concern me.

I'm using custom kernel, indeed I have to. The stock one causes random lockups. I suspect they are related to disk drivers, I can prevent them with the "noapic" boot option. I couldn't figure out which module or feature in the kernel causes the problem but I don't really bother, since my simplified custom kernel works pretty well.

things vary from distro to distro. I noticed the debian user said how much faster it made his system etc etc. I never used debian but when I had ubuntu 9.04 with a custom kernel the same system was still slower than what I'm using now, which is booting off of the slackware install disk. I've never had a need to install a custom kernel in slackware, but maybe you do. I vote for "if it aint broke don't fix it".

I vote the same: efficiency. This is important to people such as laptop users (more efficient with power usually means longer battery life).

As for bootup being faster, I can see that to a point. I would think that more modules (<M>) doesn't really matter to boot up speed since they're not "in" the bzImage, but I could be wrong.

Less problems that "could" arise? I don't see that except from a statistical basis (same logic as "the longer you leave your computer online, the more likely you are to be hacked").

Less prone to kernel exploits? I don't know if I buy that except (again) from a statistical basis, but you'd see a kernel update come out to fix the said exploit, so I don't see this being much of an issue.

This has been said before, but I'll repeat it: the huge and generic kernels are made so that they run on as many computers as possible, which is their goal, and they do it well. However, efficiency and speed can sometimes be found in tailoring the kernel for your machine (especially if you compile a kernel, which I would think everyone does when an update to the kernel comes out). Since you're already going to compile a kernel if an update comes out, might as well take a few seconds to do good. Even something as simple as specifying your CPU and disabling Generic X86 results in a smaller kernel image, which should translate into better performance.

Does anyone know of a way to test this theory, however? I'm thinking benchmarks, but what benchmarks would you think would prove or disprove efficiency theories?

As for efficiency, I can already tell you in terms of battery life that generic-smp gets about 2 hours 30 minutes out my battery, while my slap/slap64 configs get about 2 hours 40 minutes. Using hdparm to get the hard drive to spin down results in 3 hours battery life in conjunction with my slap/slap64 configs.

How small have you guys got your kernels? My current is 1645kb.

I'm at 2MB but that's my "works on everything" slap config (at least everything 586 or higher).

That sounds interesting. I have only limited experience compiling kernels, but this seems like a cool option to use.
So how does this work exactly? Do you first run "i386_defconfig" or "x86_64_defconfig" and then run "make menuconfig" or "make xconfig"?
Does this automagically compile a kernel specific for your hardware?

Without compiling modules, and with only have the actual drivers I actually need, I now bootup in less than half the time than with the generic. If nothing else, boottime will be significantly improved.

If you have additional features enabled, that you don'T need, that are unstable or have a bug, they could cause a problem. It is not the same logic as the more you are online the more likely you are to be hacked, but rather the same logic as it is good practice not to runs ervices you don't need.

Most kernel exploits have not been specific to any drivers, and would effect anyone. Still, by removing everything you don'T need, you are reduice the attack area.

You may be understating the benefits here. The huge generic kernel runs on most computers, which is its goal. It does this by sacrificing speed and efficieny. A tailered kernel will definitly result in noticably better speed and performance, in my experience.

mine stands @ 2.4MB, its a work in progress though. it takes ~25 seconds to startup.

Well it's not the same logic because modules don't respond over the internet unless that's their design. You can have those services on the machine and not running, which to me sounds like it's the same as compiling as modules but not loading them.

If most kernel exploits have not been specific to any drivers and would affect everyone, I don't see how the attack area decreased.

Still, it's your machine, have fun 8-)