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

[Carlos O'Donell <carlos at redhat dot com>]

On 09/20/2017 12:53 AM, Markus Trippelsdorf wrote:
> 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.
 
Yes, it is a hard problem.

We don't want anyone to use the *patches*, we want them to use pre-compiled
instrumented glibc to gather data at the behest of glibc developers with
cooperation from the distributions.

As luck would have it I support Fedora's glibc and so does DJ so we have
specially compiled Fedora patches to gather this information.

The goal is to eventually get trace into upstream so we can do better analysis
of all of our APIs, and so that distros can turn this on without the effort of
patching. Users just use LD_PRELOAD with a new glibc. I don't see that as too
complex (it might be invasive at a trace cost perspective, but it's less than
any other trace infrastructure I've ever seen).

Yes, they do generate a lot of data, but we need that data, and it's just a file
that users can send which has no real information about their systems. We have
had real customers work with us to gather this data, and it's on our long list to
possibly switch to HDF5 to do compressed data as an option (after trace capture).

Lastly, users don't look at code complexity at all.

In summary:

- Users should get packages from their distro to enable trace capture.
- Files are large, that hasn't stopped people from getting us short workloads.
- Analysis an issue and we continue to work on anything beyond the metrics
  the simulator provides on x86_64 (instruction counts, vmrss, vmsize).

What else can we do to make this better? To further the engineering rigor we use?

-- 
Cheers,
Carlos.