[PATCH v3 0/5] malloc: tcache improvements
Wilco Dijkstra
Wilco.Dijkstra@arm.com
Fri Mar 14 17:47:59 GMT 2025
Hi Cupertino,
> All results were taken without any tunables set, i.e. the tcache is
> still limited to roughly 1k chunks and bigger chunks caching is not
> benchmarked.
The v4 results look pretty good indeed!
> I will soon prepare the patches and submit has a new v4 series.
> For v4 I will leave the new code in isolated patches to easily follow
> the recent changes.
Could you place the simple changes in your series first please? In v4,
patch 1 and 3 look good. The inlining change v4 patch 6 is obvious too
(there was at least one other wrong use of inline). Plus any other generic
improvements like adding unlikely that apply to existing code.
However I think the pointer swizzling change (patch 2 in v3) should be
separate - it's not clear what causes the slowdown, but it is not necessary
for your later changes, right? The best solution is to remove the horrible
interfaces tache_get_n/tcache_next and replace with tache_get_aligned.
Extra pointer swizzling could then be added if the security gain is worth
the cost cost.
> Hope you see the value of running mimalloc-bench and accept it as a
> valid benchmark for the purpose.
I think it is a good idea, just need to try it out...
Btw I looked into why the bench-malloc-thread test is so sensitive - it spends
a lot of time in tcache code, so it effectively benchmarks tcache. With a few
tweaks to move unnecessary initialization out of the critical path and using
tailcalls, I got 33% speedup! That's just some basic tweaks to libc_free without
changing interfaces, so if we optimize tcache a bit more, we might get 40-50%.
Cheers,
Wilco
More information about the Libc-alpha
mailing list