This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] Consolidate heap in memalign when alignment is large.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Will Newton <will dot newton at linaro dot org>, OndÅej BÃlka <neleai at seznam dot cz>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 18 Nov 2013 13:41:24 -0500
- Subject: Re: [PATCH 1/2] Consolidate heap in memalign when alignment is large.
- Authentication-results: sourceware.org; auth=none
- References: <20131107204959 dot GA21537 at domone> <CANu=DmjyQRFXb00tf+R_WWdesM_mYnmA-0b5t6d1Q+yVD8N3hQ at mail dot gmail dot com>
On 11/08/2013 05:01 AM, Will Newton wrote:
> On 7 November 2013 20:50, OndÅej BÃlka <neleai@seznam.cz> wrote:
>> Hi,
>>
>> I looked how deduplicate malloc code. Funcions valloc/pvalloc should be
>> implemented by calling memalign, only difference is that they call heap
>> consolidation.
>>
>> If consolidation is useful then memalign would benefit when user passes
>> page size alignments. Otherwise we should delete consolidation from
>> valloc.
>>
>> Which alternative is better?
>
> I would vote for removing the consolidation call. I don't have any
> benchmarks for judging what is better and I suspect with this type of
> thing you would need a real app with does a significant amount of page
> aligned allocations which may not even exist. But pvalloc and valloc
> are much less frequently called than memalign/posix_memalign so I
> would assume the latter is the better tested code.
>
> And overall I think it is better to err on the side of simplicity,
> especially as this code has no clear rationale documented.
I agree. Removing the consolidation is the best thing to do.
Fastchunk consolidation is a black art at the moment with no
data to backup the consolidation limits or reasons and causes
no end of headaches. What we really need to a direct API to allow
users control of some of the options in malloc i.e. tunnables.
Cheers,
Carlos.