This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] malloc: Use current (C11-style) atomics for fastbin access
- From: Florian Weimer <fweimer at redhat dot com>
- To: Anton Blanchard <anton at ozlabs dot org>
- Cc: libc-alpha at sourceware dot org, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, Paul Clarke <pc at us dot ibm dot com>, Bill Schmidt <wschmidt at us dot ibm dot com>
- Date: Tue, 15 Jan 2019 23:35:58 +0100
- Subject: Re: [PATCH] malloc: Use current (C11-style) atomics for fastbin access
- References: <87va52nupb.fsf@oldenburg.str.redhat.com> <20190116092655.151bdbbd@kryten>
* Anton Blanchard:
> Hi Florian,
>
>> This is another cleanup patch in preparation of the extended heap
>> protector (which will cover the fd/bk/fd_nextsize/bk_nextsize fields
>> in struct malloc_chunk, too).
>>
>> By the way, there is an optimization opportunity for the tcache
>> backfill in _int_malloc: After the acquire MO load on the fastbin
>> list head, we can traverse the fastbin list as far as we need in
>> order to refill the tcache, and update the new list head with a
>> single CAS. This does not have races (ABA races and the like)
>> because we have acquired the arena lock at this point. Some backoff
>> is probably needed in case the fastbin list head is contended. But
>> it is probably a good idea to do the first traversal at least once.
>
> I see a 16% regression on ppc64le with a simple threaded malloc test
> case. I guess the C11 atomics aren't as good as what we have in glibc.
Uh-oh. Would you please check if replacing the two atomic_load_acquire
with atomic_load_relaxed restore the previous performance?
I believe both loads need to be acquire MO under the C11 memory model
(see the comments why), but the old code did not have them.
Thanks,
Florian