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: Jörn Engel <joern at purestorage dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, 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 11:42:42 -0800
- 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> <1453922342 dot 4592 dot 166 dot camel at localhost dot localdomain>
On Wed, Jan 27, 2016 at 08:19:02PM +0100, Torvald Riegel wrote:
>
> Then it should be sufficient if you can describe what you actually
> measured to convince Szabolcs; if your measurement is as good as you
> seem to say it is, it should be obvious why his (and your prior)
> concerns are unfounded. Up to now, you just stated that you did measure
> something.
I believe I ran my testsuite (see tarball from the other subthread) with
and without locking for the thread cache. Signal torture obviously
didn't finish without locking. The performance impact for the others
was well in the noise. Maybe with a few hundred repetitions I could
have extracted some non-noise signal, but I was happy with that result.
Since my testsuite spends >50% of the time in malloc, any real-world
results would get diluted even further.
> I'd also like to kindly point out that we're not on LKML here. We all
> will understand you better if you provide sounds arguments and provide
> the necessary background information instead of if you "call bullshit".
Fair.
I have little patience for theoretical concerns that block real
improvements based on zero evidence. But I shouldn't drop my manners
because of that. Apologies.
Jörn
--
The cheapest, fastest and most reliable components of a computer
system are those that aren't there.
-- Gordon Bell, DEC labratories