]> err.no Git - linux-2.6/commit
[POWERPC] Optimize counting distinct entries in the relocation sections
authorEmil Medve <Emilian.Medve@Freescale.com>
Tue, 13 Nov 2007 16:24:04 +0000 (03:24 +1100)
committerPaul Mackerras <paulus@samba.org>
Fri, 21 Dec 2007 04:05:58 +0000 (15:05 +1100)
commiteda09fbdcd8c5afaa81c2f1d28e8b9725bad4d5a
tree0afe6e81172fc9508f8e4c13598a276fe3d043c6
parent1fe58a875e4bb08125c657b1b91ac515d2bdbcbe
[POWERPC] Optimize counting distinct entries in the relocation sections

When a module has relocation sections with tens of thousands of
entries, counting the distinct/unique entries only (i.e. no
duplicates) at load time can take tens of seconds and up to minutes.
The sore point is the count_relocs() function which is called as part
of the architecture specific module loading processing path:

-> load_module() generic
   -> module_frob_arch_sections() arch specific
      -> get_plt_size() 32-bit
      -> get_stubs_size() 64-bit
 -> count_relocs()

Here count_relocs is being called to find out how many distinct
targets of R_PPC_REL24 relocations there are, since each distinct
target needs a PLT entry or a stub created for it.

The previous counting algorithm has O(n^2) complexity.  Basically two
solutions were proposed on the e-mail list: a hash based approach and
a sort based approach.

The hash based approach is the fastest (O(n)) but the has it needs
additional memory and for certain corner cases it could take lots of
memory due to the degeneration of the hash.  One such proposal was
submitted here:

http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037641.html

The sort based approach is slower (O(n * log n + n)) but if the
sorting is done "in place" it doesn't need additional memory.
This has O(n + n * log n) complexity with no additional memory
requirements.

This commit implements the in-place sort option.

Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
arch/powerpc/kernel/module_32.c
arch/powerpc/kernel/module_64.c