TLS performance enhancement

[GoogleCodeExporter]

libtcmalloc.so hits __tls_get_addr heavily. An oprofile of a workload that
uses new a lot shows this:

%        app name                  symbol name
10.7240  libtcmalloc_orig.so.0.0.0 operator new[](unsigned long)
 8.4210  ld-2.5.so                 __tls_get_addr

This happens because we are using __thread in an -fPIC compiled library.
Thanks to a tip from Alan Modra, we can fix this by using the initial exec
tls model. Page 34 of the following document explains it:

http://people.redhat.com/drepper/tls.pdf

Basically this optimisation can only be used in shared libraries that are
never dlopened. It would be a bug to dlopen a malloc replacement (because
we'd end up calling free on objects that were allocated by the previous
malloc) so this should be OK.

With this fix the benchmark in question improved by 18%

Original issue reported on code.google.com by anton.bl...@gmail.com on 15 Oct 2008 at 9:24

Attachments:

• tls_optimisation.patch

[GoogleCodeExporter]

Wow, good thinking!

It's not technically a bug to dlopen a malloc replacement -- if you're careful 
with
memory management, you can make sure to dlclose it at the right time so 
everything is
freed with the same allocator it was alloced with -- but it's so fragile, I'm 
happy
to disallow it.  The performance win is definitely worth it.  I'll put this in 
the
next release.

Original comment by csilv...@gmail.com on 15 Oct 2008 at 8:08

• Changed state: Started

[GoogleCodeExporter]

This patch is in perftools 1.0rc1.

However, I was made aware of a bug involving TLS with -fPIC libraries in many
versions of gcc (see http://gcc.gnu.org/ml/gcc-bugs/2006-09/msg02275.html).  
Because
of this, I now turn on TLS much more selectively than in the past.  So this 
patch may
not be as widely useful as one might hope!  Things will get better as distros 
move to
newer versions of gcc, though.

Original comment by csilv...@gmail.com on 13 Dec 2008 at 1:45

• Changed state: Fixed