kernel modules and performance

[Dazed_75]

On Nov 9, 2007 11:13 AM, der.hans <PLUGd at lufthans.com> wrote:
> moin moin,
>
> There is a performance hit for using modules rather than having the
> functionality built in to the kernel. Is that a recurring penalty once the
> module has been loaded? In other words, does the kernel have to do
> something extra each time it uses a fx() from a module?

My understanding from years ago (meaning I could be wrong) is that the
whole goal is to prevent kernel bloat while allowing access to a
potentially huge pool of drivers and other modules.  The design
allowed modules to be produced and delivered (and added) that the
kernel could use on demand.  I do not know if demand was solely based
on static configuration data or if it also allowed dynamic discovery
of need (I think it did, but ...).  Surely we have some kernel folks
that could be more authoritative, but since you have had no answer in
five hours, I stepped in.

But the design also provided that once a module was loaded, all of its
fx() were available without further loading.  Possibly that has
changed but I suspect not.

>
> Does having a whole bunch of loaded modules cause a performance hit
> because some module lookup table gets huge or for some other reason?

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.
 Surely one was the loading overhead but I have no clue whether one of
the reasons was lookup table sizes. May be more likely symbol lookup
could become an issue not just of size but frequency of lookup.  Just
my guess though.

>
> Does having unused modules that are available on the file system cause
> a performance hit for the kernel? Module dependencies are stored on disk
> and the modules aren't being used, so I think the downside would only be
> that they use more disk space. Maybe the size of resources like a module
> lookup table are determined at compile time such that having more modules
> staticly dedicates more resources to handling them...

I am pretty sure you are correct about it being just disk space.  And
further, I seem to recall talk of that being avoidable for a system
where you knew large numbers of modules that might come with an
installation might never be used and could be removed.

>
> I realize this performance hits might be slight under most circumstances.
> I want to understand whether or not they exist at all and then learn if
> there are conditions where they are significant enough to be an issue.
>
> ciao,
>
> der.hans
> --
> #  https://www.LuftHans.com/        http://www.CiscoLearning.org/
> #  I've got a photographic memory,
> #  but I'm lousy photographer. - der.hans
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>



-- 
Man is the only animal that laughs and weeps, for he is the only
animal that is struck with the difference between what things are and
what they ought to be.
  - William Hazlitt