Re: [patch] malloc per-thread cache ready for review

[Carlos O'Donell <carlos at redhat dot com>]

On 02/01/2017 12:39 PM, Zack Weinberg wrote:
> On Wed, Feb 1, 2017 at 11:44 AM, DJ Delorie <dj@redhat.com> wrote:
>>
>> Before we go down the "which allocator is best" road... glibc's
>> allocator is intended to be a general purpose "reasonably good enough"
>> system allocator.  It's easy to find a specific allocator that beats it
>> in a specific test, but being a specifically best allocator is not our
>> goal here - providing an allocator that can be the default on a
>> Linux-based system is.
> 
> Still, I would hope that if an existing alternative implementation
> (such as either of those mentioned by Markus) is found to be
> _consistently_ better than what we have, we would consider adopting
> it.
> 
> (The difficulty is of course defining "consistently".)

I don't think that's entirely true. There are non-technical issues
of copyright and licensing to consider.

See my other email in this thread to point out that we need workload
captures to generate a corpus of data to evaluate allocators.

I think there is a lot of value in glibc's malloc, and the differences
seen by most are page-based vs. heap-based allocator issues, and
how those choices tie directly into application usage patterns e.g.
producer-consumer threads vs. stack-based state machines.

-- 
Cheers,
Carlos.