This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [patch] malloc per-thread cache ready for review
- From: Markus Trippelsdorf <markus at trippelsdorf dot de>
- To: DJ Delorie <dj at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 1 Feb 2017 17:54:46 +0100
- Subject: Re: [patch] malloc per-thread cache ready for review
- Authentication-results: sourceware.org; auth=none
- References: <20170201163333.GD17590@x4> <xnefzhlv2y.fsf@greed.delorie.com>
On 2017.02.01 at 11:44 -0500, DJ Delorie wrote:
>
> Markus Trippelsdorf <markus@trippelsdorf.de> writes:
> > http://locklessinc.com/downloads/lockless_allocator_src.tgz (the best in
> > my testing) or jemalloc.
>
> 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.
>
> Hence, my goal with the per-thread cache is to make it "generally
> better" for overall system performance.
>
> I am not trying to make it better than every other allocator in every
> case, that's a futile exercise.
Well, there wouldn't be a reason for all these alternative allocators if
glibc's would be "reasonably good". In fact is often astonishingly bad.
Examples are all major browsers (using jemalloc or tcmalloc) and Rust
(jemalloc gets linkend in for all generated binaries by default).
--
Markus