[PATCH] Async signal safe TLS accesses

[Ondřej Bílka]

On Fri, Nov 29, 2013 at 01:29:49PM +0100, Ondřej Bílka wrote:
> On Thu, Nov 28, 2013 at 11:26:03PM -0500, Carlos O'Donell wrote:
> > In the end AS-safety may even limit your flexibility, but I don't
> > discount the possibility of writing the allocator such that it performs
> > well.
> > 
> Not on x86, I did a benchmark to see how big is overhead, after
> eliminating sources of noise a signal safe variant is pretty
> indistingushible from normal. There were two preventable slowdowns,
> first was that dynamic tls is access slower so we need to use static tls.
> Second was caused by gcc which emmited storing five registers at start
> of free for unlikely code for returning memory that is suppressed by
> appropriate expect.

Benchmark is here, it does repeated allocation and deallocation, I ran
frequency/10 iterations of malloc/free with given wrapper on ivy bridge,

A plain version takes around 107 cycles, intercepting and tls cost
around 10 cycles, if we look to tls only it is around 3 cycles in
malloc. You would need to make allocator a magnitude faster to make this
noticable factor, costs for other architectures differ.

plain


real	0m10.753s
user	0m10.757s
sys	0m0.000s
normal


real	0m11.518s
user	0m11.521s
sys	0m0.000s
signal safe


real	0m11.733s
user	0m11.737s
sys	0m0.000s
plain


real	0m10.753s
user	0m10.757s
sys	0m0.000s
normal


real	0m11.274s
user	0m11.274s
sys	0m0.003s
signal safe


real	0m11.732s
user	0m11.736s
sys	0m0.000s

-------------- next part --------------
A non-text attachment was scrubbed...
Name: malloctest.tar.bz2
Type: application/octet-stream
Size: 13558 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20131130/01c8e6a5/attachment.obj>