Re: [PATCH][malloc] Avoid atomics in have_fastchunks

[DJ Delorie <dj at redhat dot com>]

Wilco Dijkstra <Wilco.Dijkstra@arm.com> writes:
> An alternative would be to move all the fastbin handling into the
> t-cache - but then I bet it's much easier just to write a fast modern
> allocator...

tcache is a type of fastbin already.  I tested removing fastbins since
tcache did something similar, but it turns out that doing both tcache
and fastbins is still faster than doing just either.

Many have said "just replace glibc's malloc with a fast modern
allocator" but glibc's malloc is about as fast as a modern allocator
now, and what we're lacking is a way to *prove* a new malloc is faster
for all the use cases glibc needs to cater to.  I posted a note about
the trace-enabled glibc hoping that folks would start collecting the
workloads we want to benchmark.  Having a large library of
benchmark-able things is somewhat of a prerequisite before we worry
about "which malloc is faster for glibc's audience".

I'm not saying we should never replace glibc's malloc, I'm saying we
need solid metrics to justify it.  Remember that glibc's allocator is
the default allocator for all of Linux, aside from the few apps that
have an app-specific allocator.

Thus, "I bet it's much easier" is not such a sure bet ;-)