Enhancing malloc

[Ondřej Bílka]

On Tue, May 28, 2013 at 12:11:01PM +0100, Will Newton wrote:
> Hi all,
> 
> 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

There was discussion on planning for 2.18 thread, did you read following?
http://sourceware.org/glibc/wiki/Development_Todo/Enhancing_malloc 

> 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.
> 
One of possible improvements is using atomic operations so we do not
have lock. However I do not know how effective are atomic operations 
on ARM.

> If we were to submit changes to the malloc implementation what set of
> benchmark numbers would be required?

Malloc and friends are one of few libc functions which can be measured
directly. They account to about 50% of time spend in libc. I know that gcc
hevavily uses malloc. So authoritative test could be if following is 
improvement or not:

for I in `seq 1 10` do
echo new
LD_PRELOAD=new_malloc.so time gcc test.c
echo old
time gcc test.c
done

You must take into account that malloc requests are small. I did some
measurements at
http://kam.mff.cuni.cz/~ondra/benchmark_string/malloc_profile_28_11_2012.tar.bz2 

> Would it be acceptable to have build time selection of multiple malloc
> implementations?

Selection would be good but build time is too early. Different
applications need different allocators so we could add
mallopt/environment variable option. 
Or do profiling to automatically determine what is best.

> Is anyone else already working on this?
>
I have some ideas and will start working on it after 2.18