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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
