when building the linux kernel with btf info, a pahole invocation such as
pahole -J --btf_gen_floats -j '--lang_exclude=rust'
--skip_encoding_btf_inconsistent_proto
--btf_gen_optimized .tmp_vmlinux.btf
is ran.
the vmlinux symbol list is extremely large- so this allocated_entry
size grows in small 2048 increments each time, and runs realloc.
outside of glibc (with e.g. musl's malloc-ng allocator, or the llvm
scudo allocator), this seems to be a particularly expensive operation
that ends up repeatedly memcpy'ing the memory into the new realloc over
and over again.
on my hardware, this exponential realloc strategy makes the pahole
invocation on vmlinux.o go from 60 seconds to 25 due to significantly
lower reallocation pressure.
Signed-off-by: psykose <alice@xxxxxxxxx>
---
dwarves.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dwarves.c b/dwarves.c
index 1ec259f..dc72d65 100644
--- a/dwarves.c
+++ b/dwarves.c
@@ -566,7 +566,7 @@ static int ptr_table__add(struct ptr_table *pt, void *ptr, uint32_t *idxp)
const uint32_t rc = pt->nr_entries;
if (nr_entries > pt->allocated_entries) {
- uint32_t allocated_entries = pt->allocated_entries + 2048;
+ uint32_t allocated_entries = pt->allocated_entries < 2048 ? 2048 : pt->allocated_entries * 2;;
void *entries = realloc(pt->entries,
sizeof(void *) * allocated_entries);
if (entries == NULL)
base-commit: 3e265dac5ec85b956c664464072196c37d2af4f3
--
2.45.2
