summaryrefslogtreecommitdiffstats
path: root/certs/Kconfig
diff options
context:
space:
mode:
authorPeter Zijlstra <peterz@infradead.org>2021-05-06 21:33:53 +0200
committerIngo Molnar <mingo@kernel.org>2021-05-12 14:54:50 +0200
commit25cf0d8aa2a3440ed32bf1f8df1310d6baf3f1e8 (patch)
tree5dc4498dea4c98e90b87942754f16068b7161bef /certs/Kconfig
parent6efb943b8616ec53a5e444193dccf1af9ad627b5 (diff)
downloadlinux-25cf0d8aa2a3440ed32bf1f8df1310d6baf3f1e8.tar.bz2
objtool: Rewrite hashtable sizing
Currently objtool has 5 hashtables and sizes them 16 or 20 bits depending on the --vmlinux argument. However, a single side doesn't really work well for the 5 tables, which among them, cover 3 different uses. Also, while vmlinux is larger, there is still a very wide difference between a defconfig and allyesconfig build, which again isn't optimally covered by a single size. Another aspect is the cost of elf_hash_init(), which for large tables dominates the runtime for small input files. It turns out that all it does it assign NULL, something that is required when using malloc(). However, when we allocate memory using mmap(), we're guaranteed to get zero filled pages. Therefore, rewrite the whole thing to: 1) use more dynamic sized tables, depending on the input file, 2) avoid the need for elf_hash_init() entirely by using mmap(). This speeds up a regular kernel build (100s to 98s for x86_64-defconfig), and potentially dramatically speeds up vmlinux processing. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20210506194157.452881700@infradead.org
Diffstat (limited to 'certs/Kconfig')
0 files changed, 0 insertions, 0 deletions