Am 09. Nov, 2007 schwätzte Dazed_75 so:
> On Nov 9, 2007 11:13 AM, der.hans <PLUGd@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.
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 -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)