[PATCH] malloc: fix large tcache code to check for exact size match

[Dev Jain]

On 30/09/25 12:24 pm, Dev Jain wrote:
>
> 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.

I wrapped the e_size != nb with __glibc_unlikely(), and then 
__glibc_likely(), for

both the cases, the result worsens to 8.07, 7.5. So this should mean 
that the

branch e_size != nb is expensive.