Re: TLS bug?

On 06/17/2011 02:35 PM, Marius Strobl wrote:
> On Fri, Jun 17, 2011 at 03:31:29PM -0400, Nathaniel W Filardo wrote:
>> On Fri, Jun 17, 2011 at 08:07:13PM +0200, Marius Strobl wrote:
>>> Using bonnie++ I can't reproduce this (didn't try mysql) but I have
>>
>> I seem to have good luck reproducing it with "-r 5 -s 10 -x 10" by about the
>> third iteration.
>
> Ok, with these parameters I can reproduce it.
>
>>
>>> some TLS fixes for libthr I forgot about but could be relevant here
>>> (most actually date back to 2008 when the base binutils didn't support
>>> GNUTLS for sparc64 so I couldn't test them easily). Could you please
>>> give a libthr build with the following patch a try?
>>> http://people.freebsd.org/~marius/libthr_sparc64.diff
>>
>> Concurrent runs both with and without those diffs still asserted.
>> Interestingly, libc's .tbss section, even after the assertion, is still full
>> of zeros, so it looks like something stranger than a wild-write back to
>> .tbss.  I'll go diving through the tls allocation code again when I get a
>> minute.
>>
>
> In combination with the below patch bonnie++ survived 100 iterations
> here. I'm not sure what this means though as I don't have much knowledge
> about TLS, I merely implemented the necessary relocations. Could be
> that malloc() actually requires the initial exec model for variant II.
> Unfortunately, it's not documented why it was added for x86.
> Jason, can you shed some light on this?
>
> Marius
>
> Index: malloc.c
> ===================================================================
> --- malloc.c	(revision 219535)
> +++ malloc.c	(working copy)
> _at__at_ -234,7 +234,7 _at__at_
>   #ifdef __sparc64__
>   #  define LG_QUANTUM		4
>   #  define LG_SIZEOF_PTR		3
> -#  define TLS_MODEL		/* default */
> +#  define TLS_MODEL		__attribute__((tls_model("initial-exec")))
>   #endif
>   #ifdef __amd64__
>   #  define LG_QUANTUM		4
>

I added the initial-exec TLS_MODEL because it is faster than the 
default; jemalloc in no way depends on this for correctness though, so 
your patch is safe.

Thanks,
Jason