This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] malloc: add locking to thread cache
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: JÃrn Engel <joern at purestorage dot com>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: Yury Gribov <y dot gribov at samsung dot com>, Florian Weimer <fweimer at redhat dot com>, "GNU C. Library" <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, nd at arm dot com
- Date: Wed, 27 Jan 2016 16:36:04 -0500
- Subject: Re: [PATCH] malloc: add locking to thread cache
- Authentication-results: sourceware.org; auth=none
- References: <1453767942-19369-1-git-send-email-joern at purestorage dot com> <1453767942-19369-52-git-send-email-joern at purestorage dot com> <56A76A49 dot 8010804 at arm dot com> <56A77149 dot 1090204 at redhat dot com> <56A77356 dot 9070503 at samsung dot com> <56A7773A dot 4070706 at arm dot com> <20160126180023 dot GD14840 at vapier dot lan> <56A8966D dot 9080000 at arm dot com> <20160127174440 dot GR5745 at Sligo dot logfs dot org>
On 01/27/2016 12:44 PM, Jörn Engel wrote:
> On Wed, Jan 27, 2016 at 10:05:33AM +0000, Szabolcs Nagy wrote:
>>
>> portable code does not need the fix, but all users
>> of the api are affected by the overhead of the fix.
>
> Sorry, but you have no idea what you are talking about. The overhead of
> the fix is _negative_. Users _want_ to be affected.
>
> The reason why free() is not signalsafe is that it spins on an
> arena-lock. If the same thread already holds that lock, you have a
> classic deadlock. By not spinning on the lock you make code run faster.
> You also fix the signal-induced deadlock.
>
> Ok, for thread-cache there is some overhead. Without signal-safety you
> wouldn't need a lock for the thread-cache at all. But here I call
> bullshit again, because I had the same concerns. Then I measured and
> could not demonstrate any performance impact.
>
> "If you cannot measure it, it does not exist."
>
> You might disagree philosophically, but if an engineers goes out of his
> way to measure a certain effect and finds nothing, that effect hardly
> matters in any practical way.
My mantra is slightly different:
"If others cannot measure it, your performance gains don't exist."
We are always looking for microbenchmark contributions that others
can run objectively to evaluate any such changes.
Cheers,
Carlos.