Please note that User Registration has been temporarily disabled due to a recent increase in automated registrations. If anyone needs an account, please request one here: RequestAccount. Thanks for your patience!--Wmat (talk)
Please email User:Wmat if you experience any issues with the Request Account form.

Hardcode kernel module info

Revision as of 23:24, 18 September 2007 by Tim Bird (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Sony found that with the 2.4 kernel, and an extremely large kernel loadable module, it could take the kernel module loader up to 3 seconds just to scan the relocation table for the module in order to load it.

The following patch allows one to pass some arguments to the kernel command line to hardcode some of the information that is detected at module load time. This reduced the module load time significantly for this situation.

This is a very specialized problem, but in case some one finds this useful, here's a more detailed description of the problem, and a patch:

Detailed problem description

We've found that module_frob_arch_sections(ppc) takes a long time to find unique symbols in the relocation sections of the kernel module's elf header.

Our particular kernel module had a relocation section with 13757 entries(2749 unique ones) in it, and for this module, we measured 3 seconds to process this section by count_reloc function.

(There may be a way to not generate all this many entries, or not do the relocations in insmod etc... but we don't know about it at this time.)

We made a patch to just work around this problem by just passing the size info by the argument when insmod happens, and not do actual counting.

-Whether we should think of fixing the count algorithm or other proper way of fixing this. -Whether we should think of an option not to do any relocations at all

Patch for 2.4.17 kernel