This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Enhancing malloc
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Will Newton <will dot newton at linaro dot org>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 28 May 2013 14:33:17 +0200
- Subject: Re: Enhancing malloc
- References: <CANu=Dmj34hZoWr8A5dPThv14XUmP8vTgsxFLAbJ9jTTabRPqqA at mail dot gmail dot com>
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