Am 09. Nov, 2007 schwätzte Dazed_75 so:
On Nov 9, 2007 11:13 AM, der.hans <[EMAIL PROTECTED]> 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.
Thanks :).
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.
Yeah, I think they're still available without further loading, provided
the module wasn't unloaded, but I'm just wondering if there's other
overhead such as multiple lookups to get to the fx().
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.
Yeah, I'm wondering if there's any advantage to the kernel for removing
unused modules. If there were I'd think that decision would need to be
made at compile-time.
danke,
der.hans
--
# https://www.LuftHans.com/ http://www.CiscoLearning.org/
# Knowledge is useless unless it's shared. - der.hans
---------------------------------------------------
PLUG-discuss mailing list - [email protected]
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
