TLS bug?
Jason Evans
jasone at canonware.com
Tue Jun 21 16:49:37 UTC 2011
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)
> @@ -234,7 +234,7 @@
> #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
More information about the freebsd-sparc64
mailing list