[PATCH] malloc: fix large tcache code to check for exact size match
Dev Jain
dev.jain@arm.com
Tue Sep 30 06:54:57 GMT 2025
On 29/09/25 11:19 pm, Wilco Dijkstra wrote:
> Hi Dev,
>
>> The tcache is used for allocation only if an exact match is found. In the
>> large tcache code added in commit cbfd7988107b, we currently extract a
>> chunk of size greater than or equal to the size we need, but don't check
>> strict equality. This patch fixes that behaviour.
> Good find!
>
>> Signed-off-by: Dev Jain <dev.jain@arm.com>
> You don't need to add this.
Okay.
>
>> I couldn't get a visible perf improvement on running the largetcache
>> versions of the tests in the malloc testsuite, for example,
>> ./tst-aligned-alloc-random-malloc-largetcache.
> Those are testcases and not suitable as benchmarks. bench-malloc-tcache
> can be used to test tcache performance of large blocks if you run it with
> GLIBC_TUNABLES=glibc.malloc.tcache_max=65536 and pass a larger size.
I did
make bench BENCHSET="malloc-tcache" and ran
GLIBC_TUNABLES=glibc.malloc.tcache_max=65536 ./bench-malloc-tcache 2048. There are
two values for time_per_iteration:
without patch - 7.6, 7.12
with patch - 7.99, 7.41
so that's a regression; I am not sure if this is the correct benchmark. My patch
will *not* retrieve from the tcache (which is the fastest path in the malloc code)
if there is a size mismatch, but will stop fragmentation. I suppose we have to run
a longer benchmark so that we can see the memory benefits.
>
> It may be interesting to run SPECINT with this setting (or a larger size) to see
> whether it has any effect.
>
>> + e = mangled ? REVEAL_PTR (*entry) : *entry;
>> + if (e == NULL)
>> + return NULL;
>>
>> + e_size = chunksize (mem2chunk (e));
>> + if (e_size != nb)
>> return NULL;
> Why not write it like:
>
> tcache_entry *e = mangled ? REVEAL_PTR (*entry) : *entry;
> if (e == NULL || chunksize (mem2chunk (e)) != nb)
> return NULL;
Sure!
> Cheers,
> Wilco
More information about the Libc-alpha
mailing list