[PATCH][malloc] Avoid atomics in have_fastchunks

[Markus Trippelsdorf]

On 2017.09.19 at 17:30 -0400, DJ Delorie wrote:
> 
> 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".

The reason why nobody uses your trace/simulation patches is because they
generate way too much data and are just too complex/invasive for most
users. And someone would have to analyze all this data.
So it is natural to look for other metrics like code complexity instead.

-- 
Markus