Enhancing malloc

[Siddhesh Poyarekar]

On Tue, May 28, 2013 at 11:14:28PM -0400, Mike Frysinger wrote:
> On Tuesday 28 May 2013 07:11:01 Will Newton wrote:
> > Internally a number of benchmarks and workloads have been shown to
> > spend a relatively large amount of time in the allocator, so we've
> > been looking at improving performance of glibc malloc. Specifically I
> > think we would be looking more at the performance of the allocator
> > itself (e.g. locking overhead) rather than it's interaction with the
> > kernel VM.
> > 
> > If we were to submit changes to the malloc implementation what set of
> > benchmark numbers would be required?
> > Would it be acceptable to have build time selection of multiple malloc
> > implementations?
> > Is anyone else already working on this?
> 
> i wonder if we should require any changes to be preceded by the inclusion of 
> tests and/or benchmarks, or maybe a new repo to hold things if those are too 
> large ?  having a centralized place of memory related tests/benchmarks that 
> are agreed upon in terms of "this is the baseline you should use for 
> optimizing" would go a long way.  otherwise, we have one person setting up an 
> environment, doing some work, and then throwing it all away once changes get 
> merged which makes it harder for the next person to experiment.
> -mike

This could fit in well with the separate benchmark tests[1] idea I had
for string benchmarks.  If Will can come up with independent benchmark
tests for malloc and friends, I can help to integrate those into
benchtests.  Of course, if he comes up with tests integrated into the
benchtest framework then it would be even cooler ;)

Siddhesh

[1] http://sourceware.org/ml/libc-alpha/2013-04/msg00480.html