This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Enhancing malloc
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Will Newton <will dot newton at linaro dot org>
- 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 09:00:16 -0400
- 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> <CANu=DmgciQkeWfS8TBq2FVokBQXQCG2V6tmYU+9jhmfCF_9GcQ at mail dot gmail dot com>
On 05/29/2013 03:29 AM, Will Newton wrote:
> 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?
The goal of the current code is to be FAST while still being
considerate when it comes to memory consumption.
> I agree that a comprehensive set of benchmarks would seem to be the
> logical first step.
Agreed. We have a benchmark framework in glibc, see benc/*.
Cheers,
Carlos.