kernel modules and performance

[Matt Graham]

From: Darrin Chandler <dwchandler at stilyagin.com>
> On Sat, Nov 10, 2007 at 12:55:44PM -0700, der.hans wrote:
> >>> Does having a whole bunch of loaded modules cause a performance hit
> >>> because some module lookup table gets huge or for some other reason?
> See above. *IF* above is how it's done, then after fixup it's quick from
> then on, however many modules are loaded.

FWIW, I did a short real-world test (copying 690M of data multiple times)
with e1000 compiled in and as a module.  Results:

module        compiled in
0m27.004s     0m27.172s
0m26.192s     0m26.089s
0m25.957s     0m26.055s
0m25.952s     0m25.971s
0m25.982s     0m25.963s

...if anything, the module was faster.  This doesn't make much sense to me,
but it could be that the module overhead is lost in the noise of other
junk that was going on.  Not that there was much--gettys, the KDM greeter,
sshd, and the tiny script copying and timing things.

> >> Again, I am not sure but I believe there were a couple of reasons one
> >> preferred the compiled in method rather than loading separate
> >> modules.

A while back, ISTR something from the kernel mailing list about how they
were going to change everything.  No compiling things in, no modules,
just about every driver that got built would be loaded into a RAMdisk or
a cramfs or something.  That didn't work out.

> Why would you NOT compile in the NIC driver?[1]
> There's no way it should be slower,

No, but it might be!  I could try some more tests later and see if there's
any sort of pattern at all or the thing's just messing with my head.

> suspect you'd find is that the performance differences won't make much
> difference after the system is up and running and modules are loaded. By
> the time those few machine cycles become critical you're already at the
> ragged edge of being overloaded

Aye.  You actually might be better off moving to baselayout2 (init scripts
written in C instead of sh) to save cycles instead of messing with modules
or the lack thereof.