[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