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

[Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>]

DJ Delorie wrote:
> 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.

Given tcache works in a limited set of circumstances, that's not a surprise!
Particularly the default setting only allows 7 entries which doesn't help
any workloads I've tried. From > 100 gains appear, while 250-1000 looks
quite good. So that's the kind of setting we need before fastbins could be
considered for removal. Also while tcache would need consolidation support
to limit fragmentation, it would need to be less aggressive than it is today.
It appears a fair amount of tache gains are due to better spatial locality.

> 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 ;-)

I agree we need some benchmarks and workloads. But it's not only about
getting a few percent speedup. The current implementation is without a
doubt ancient and extremely hard to understand. There are about 100
if statements in the fast paths, 90% of which are completely redundant.
It even manages to check for the exact same special case several times in
a row (eg. mmap).

The sort of questions my simple patch raises is another example of how
complex and nontrivial it has become. So there are very solid reasons to
look beyond the current implementation. I would find it hard to believe
there aren't multiple more advanced implementations available that not
only improve performance but have a significantly simpler and smaller
codebase as well...

Wilco