This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Enhancing malloc
- From: Will Newton <will dot newton at linaro dot org>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, Ondřej Bílka <neleai at seznam dot cz>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Wed, 29 May 2013 08:29:44 +0100
- Subject: Re: Enhancing malloc
- References: <CANu=Dmj34hZoWr8A5dPThv14XUmP8vTgsxFLAbJ9jTTabRPqqA at mail dot gmail dot com> <20130528123317 dot GA17360 at domone dot kolej dot mff dot cuni dot cz> <20130528125444 dot GC2145 at spoyarek dot pnq dot redhat dot com> <51A50991 dot 7010100 at redhat dot com>
On 28 May 2013 20:46, Carlos O'Donell <carlos@redhat.com> wrote:
> On 05/28/2013 08:54 AM, Siddhesh Poyarekar wrote:
>> On Tue, May 28, 2013 at 02:33:17PM +0200, OndÅej BÃlka wrote:
>>> 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
>>
>> For malloc and friends, the comparison should also include the effect
>> of the change on fragmentation (internal as well as external) and not
>> just speed of execution.
>
> I agree.
>
> In glibc's allocator we consciously try to collesce fastbins and use
> MADV_DONTNEED to give back unused pages.
>
> We could get a performance boost by looking at the new vrange support.
> Such support has already been tested in jemalloc and shown to potentially
> improve performance.
Are there specific design goals of the current code? For example, if a
new implementation increased memory usage but increased performance
would that be acceptable?
I agree that a comprehensive set of benchmarks would seem to be the
logical first step.
--
Will Newton
Toolchain Working Group, Linar