diff options
| author | Kevin Cernekee <cernekee@gmail.com> | 2012-01-13 00:02:14 +0100 |
|---|---|---|
| committer | Rusty Russell <rusty@rustcorp.com.au> | 2012-01-13 00:02:14 +0100 |
| commit | 48fd11880b5ef04270be8a87d9a9a9ee2fdae338 (patch) | |
| tree | 1dc62486665f1d28e74a0e12fec5f01beb233313 /Makefile | |
| parent | module: Add comments describing how the "strmap" logic works (diff) | |
| download | linux-48fd11880b5ef04270be8a87d9a9a9ee2fdae338.tar.xz linux-48fd11880b5ef04270be8a87d9a9a9ee2fdae338.zip | |
module: Fix performance regression on modules with large symbol tables
Looking at /proc/kallsyms, one starts to ponder whether all of the extra
strtab-related complexity in module.c is worth the memory savings.
Instead of making the add_kallsyms() loop even more complex, I tried the
other route of deleting the strmap logic and naively copying each string
into core_strtab with no consideration for consolidating duplicates.
Performance on an "already exists" insmod of nvidia.ko (runs
add_kallsyms() but does not actually initialize the module):
Original scheme: 1.230s
With naive copying: 0.058s
Extra space used: 35k (of a 408k module).
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
LKML-Reference: <73defb5e4bca04a6431392cc341112b1@localhost>
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions