This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] Single thread optimization for malloc atomics
- From: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Date: Wed, 30 Apr 2014 11:25:36 -0300
- Subject: Re: [PATCH 1/2] Single thread optimization for malloc atomics
- Authentication-results: sourceware.org; auth=none
- References: <53610133 dot 3070908 at linux dot vnet dot ibm dot com> <20140430141845 dot GA6882 at domone dot podge>
On 30-04-2014 11:18, OndÅej BÃlka wrote:
> On Wed, Apr 30, 2014 at 10:57:07AM -0300, Adhemerval Zanella wrote:
>> This patch adds a single-thread optimization for malloc atomic usage to
>> first check if process is single-thread (ST) and if so use normal
>> load/store instead of atomic instructions.
>>
> How fast is tls on power? When we add a per-thread cache as I suggested
> then it would have most of time same performance as singlethread, with
> overhead one tls variable access per malloc call.
>
The question is subtle, you mean compared to what? Others memory allocators
that per-thread cache shows good performance using TLS.
Anyway, *now* this lock is an issue that has being circumvented in a
arch-specific way (at least for x86_64). I know that is not the best way
to fix all current malloc issues, but it something we can optimize for
single-thread that has minor code impacts.