This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Alignment of malloc returned pointer
- From: Will Newton <will dot newton at linaro dot org>
- To: Ramana <ramana dot venkat83 at gmail dot com>
- Cc: Andreas Schwab <schwab at suse dot de>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 11 Dec 2014 12:00:57 +0000
- Subject: Re: Alignment of malloc returned pointer
- Authentication-results: sourceware.org; auth=none
- References: <CAF4ZLkuxQ=n2SOk1B7DB18cx_8nsrfpKmq_GR6wc76o+zVeExg at mail dot gmail dot com> <mvm61diqw9c dot fsf at hawking dot suse dot de> <CAF4ZLkuT5aFE5-hCmd32bnhc1S8JgASXy7j105G_15_FYdtENw at mail dot gmail dot com>
On 11 December 2014 at 11:37, Ramana <ramana.venkat83@gmail.com> wrote:
> On Thu, Dec 11, 2014 at 4:38 PM, Andreas Schwab <schwab@suse.de> wrote:
>> Ramana <ramana.venkat83@gmail.com> writes:
>>
>>> In glibc, I understand that the alignment of the pointer returned by
>>> malloc is aligned to at least __alignof__ (long double). For our
>>> target, we want to have a different version of malloc that return the
>>> pointer with less alignment compared to __alignof__ (long double) and
>>> leave the existing malloc version as is.
>>
>> Why do you want that?
>>
>> Andreas.
>>
>
> Because we found that some of our applications are performing better
> with less alignment for the malloc returned pointer and we want to
> give the user an option to chose between the malloc with less vs at
> least __alignof__ (long double) alignment.
There are a number of third party mallocs available (jemalloc,
tcmalloc, etc.) which have different performance characteristics. It
sounds like you are interested in reducing internal fragmentation but
it is unlikely any of the commonly used malloc replacements will help
with that as most of them are aimed at bigger systems and high
performance. I would recommend you look at your application and see if
it can be modified to use some kind of specialized allocator for what
sounds like a specialized situation (lots of tiny allocations).
--
Will Newton
Toolchain Working Group, Linaro