public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] Elision, both for s390 and x86_64, should be enabled via --enable-lock-elision=yes.
@ 2014-09-29 19:55 Carlos O'Donell
  2014-09-29 22:43 ` Andreas Schwab
  2014-09-30 12:12 ` Andreas Krebbel
  0 siblings, 2 replies; 4+ messages in thread
From: Carlos O'Donell @ 2014-09-29 19:55 UTC (permalink / raw)
  To: GNU C Library, Andreas Krebbel; +Cc: Andi Kleen, Siddhesh Poyarekar

Andreas,

All lock elision enablement should be controlled by the
--enable-lock-elision configure option.

I have already written to Andi about this, and he agreed
that it's OK for x86_64, and is what we agreed upon at
the global level for glibc.

Would you agree that this is also OK for s390?

The goal is to be able to enable or disable lock elision
for all architectures with a single configure option.

I understand that this is slightly different from what
we do for other features that we simply detect and use.

We do it this way for elision to give distributions the
flexibility because this feature is quite new and has potential
side-effects that perhaps might only be best enabled in a newer
version of the distribution.

It also gives users the ability to disable it if it's causing
problems for applications that are important to their use
cases, but that don't work well with elision.

In the long term I expect that runtime tunnables will be useful
in enabling or disabling elision on a per-application basis.

OK to commit for s390?

2014-09-29  Carlos O'Donell  <carlos@redhat.com>

	* configure.ac: --enable-lock-elision enables or disables
	all elision for locks, not just mutexes.
	* configure: Regenerate.
	* sysdeps/unix/sysv/linux/s390/elision-conf.c (elision_init)
	[!ENABLE_LOCK_ELISION]: Set __pthread_force_elision to zero.
	* sysdeps/unix/sysv/linux/x86/elision-conf.c (elision_init)
	[!ENABLE_LOCK_ELISION]: Set __pthread_force_elision,
	__elision_available, and __elision_aconf.retry_try_xbegin to zero.

diff --git a/configure b/configure
index 89566c5..9a9cf08 100755
--- a/configure
+++ b/configure
@@ -1413,7 +1413,7 @@ Optional Features:
                           initialize __stack_chk_guard canary with a random
                           number at program start
   --enable-lock-elision=yes/no
-                          Enable lock elision for pthread mutexes by default
+                          Enable hardware lock elision by default
   --enable-add-ons[=DIRS...]
                           configure and build add-ons in DIR1,DIR2,... search
                           for add-ons if no parameter given
diff --git a/configure.ac b/configure.ac
index 82d0896..d113772 100644
--- a/configure.ac
+++ b/configure.ac
@@ -169,7 +169,7 @@ fi
 
 AC_ARG_ENABLE([lock-elision],
 	      AC_HELP_STRING([--enable-lock-elision[=yes/no]],
-			     [Enable lock elision for pthread mutexes by default]),
+			     [Enable hardware lock elision by default]),
 	      [enable_lock_elision=$enableval],
 	      [enable_lock_elision=no])
 AC_SUBST(enable_lock_elision)
diff --git a/sysdeps/unix/sysv/linux/s390/elision-conf.c b/sysdeps/unix/sysv/linux/s390/elision-conf.c
index 69c0483..852433e 100644
--- a/sysdeps/unix/sysv/linux/s390/elision-conf.c
+++ b/sysdeps/unix/sysv/linux/s390/elision-conf.c
@@ -60,11 +60,16 @@ elision_init (int argc __attribute__ ((unused)),
 	      char **argv  __attribute__ ((unused)),
 	      char **environ)
 {
+#ifdef ENABLE_LOCK_ELISION
   /* Set when the CPU and the kernel supports transactional execution.
      When false elision is never attempted.  */
   int elision_available = (GLRO (dl_hwcap) & HWCAP_S390_TE) ? 1 : 0;
 
   __pthread_force_elision = __libc_enable_secure ? 0 : elision_available;
+#else
+  /* This configuration has elision disabled.  */
+  __pthread_force_elision = 0;
+#endif
 }
 
 #ifdef SHARED
diff --git a/sysdeps/unix/sysv/linux/x86/elision-conf.c b/sysdeps/unix/sysv/linux/x86/elision-conf.c
index 28e48d9..abc42b7 100644
--- a/sysdeps/unix/sysv/linux/x86/elision-conf.c
+++ b/sysdeps/unix/sysv/linux/x86/elision-conf.c
@@ -62,12 +62,17 @@ elision_init (int argc __attribute__ ((unused)),
 	      char **argv  __attribute__ ((unused)),
 	      char **environ)
 {
-  __elision_available = HAS_RTM;
 #ifdef ENABLE_LOCK_ELISION
+  __elision_available = HAS_RTM;
   __pthread_force_elision = __libc_enable_secure ? 0 : __elision_available;
-#endif
   if (!HAS_RTM)
-    __elision_aconf.retry_try_xbegin = 0; /* Disable elision on rwlocks */
+    __elision_aconf.retry_try_xbegin = 0; /* Disable elision on rwlocks.  */
+#else
+  /* This configuration has elision disabled.  */
+  __elision_available = 0;
+  __pthread_force_elision = 0;
+  __elision_aconf.retry_try_xbegin = 0;
+#endif
 }
 
 #ifdef SHARED
---

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Elision, both for s390 and x86_64, should be enabled via --enable-lock-elision=yes.
  2014-09-29 19:55 [PATCH] Elision, both for s390 and x86_64, should be enabled via --enable-lock-elision=yes Carlos O'Donell
@ 2014-09-29 22:43 ` Andreas Schwab
  2014-09-29 23:01   ` Carlos O'Donell
  2014-09-30 12:12 ` Andreas Krebbel
  1 sibling, 1 reply; 4+ messages in thread
From: Andreas Schwab @ 2014-09-29 22:43 UTC (permalink / raw)
  To: Carlos O'Donell
  Cc: GNU C Library, Andreas Krebbel, Andi Kleen, Siddhesh Poyarekar

"Carlos O'Donell" <carlos@redhat.com> writes:

> diff --git a/configure b/configure
> index 89566c5..9a9cf08 100755
> --- a/configure
> +++ b/configure
> @@ -1413,7 +1413,7 @@ Optional Features:
>                            initialize __stack_chk_guard canary with a random
>                            number at program start
>    --enable-lock-elision=yes/no
> -                          Enable lock elision for pthread mutexes by default
> +                          Enable hardware lock elision by default
>    --enable-add-ons[=DIRS...]
>                            configure and build add-ons in DIR1,DIR2,... search
>                            for add-ons if no parameter given
> diff --git a/configure.ac b/configure.ac
> index 82d0896..d113772 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -169,7 +169,7 @@ fi
>  
>  AC_ARG_ENABLE([lock-elision],
>  	      AC_HELP_STRING([--enable-lock-elision[=yes/no]],

While you are at it, please remove [=yes/no].  This is common to all
--enable- options, and as you see above this is underquoted, so that the
brackets are eaten by m4.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Elision, both for s390 and x86_64, should be enabled via --enable-lock-elision=yes.
  2014-09-29 22:43 ` Andreas Schwab
@ 2014-09-29 23:01   ` Carlos O'Donell
  0 siblings, 0 replies; 4+ messages in thread
From: Carlos O'Donell @ 2014-09-29 23:01 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: GNU C Library, Andreas Krebbel, Andi Kleen, Siddhesh Poyarekar

On 09/29/2014 06:43 PM, Andreas Schwab wrote:
> "Carlos O'Donell" <carlos@redhat.com> writes:
> 
>> diff --git a/configure b/configure
>> index 89566c5..9a9cf08 100755
>> --- a/configure
>> +++ b/configure
>> @@ -1413,7 +1413,7 @@ Optional Features:
>>                            initialize __stack_chk_guard canary with a random
>>                            number at program start
>>    --enable-lock-elision=yes/no
>> -                          Enable lock elision for pthread mutexes by default
>> +                          Enable hardware lock elision by default
>>    --enable-add-ons[=DIRS...]
>>                            configure and build add-ons in DIR1,DIR2,... search
>>                            for add-ons if no parameter given
>> diff --git a/configure.ac b/configure.ac
>> index 82d0896..d113772 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -169,7 +169,7 @@ fi
>>  
>>  AC_ARG_ENABLE([lock-elision],
>>  	      AC_HELP_STRING([--enable-lock-elision[=yes/no]],
> 
> While you are at it, please remove [=yes/no].  This is common to all
> --enable- options, and as you see above this is underquoted, so that the
> brackets are eaten by m4.

Done. Thanks for the review.

Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Elision, both for s390 and x86_64, should be enabled via --enable-lock-elision=yes.
  2014-09-29 19:55 [PATCH] Elision, both for s390 and x86_64, should be enabled via --enable-lock-elision=yes Carlos O'Donell
  2014-09-29 22:43 ` Andreas Schwab
@ 2014-09-30 12:12 ` Andreas Krebbel
  1 sibling, 0 replies; 4+ messages in thread
From: Andreas Krebbel @ 2014-09-30 12:12 UTC (permalink / raw)
  To: Carlos O'Donell, GNU C Library; +Cc: Andi Kleen, Siddhesh Poyarekar

On 09/29/2014 09:55 PM, Carlos O'Donell wrote:
> Andreas,
> 
> All lock elision enablement should be controlled by the
> --enable-lock-elision configure option.
> 
> I have already written to Andi about this, and he agreed
> that it's OK for x86_64, and is what we agreed upon at
> the global level for glibc.
> 
> Would you agree that this is also OK for s390?
> 
> The goal is to be able to enable or disable lock elision
> for all architectures with a single configure option.
> 
> I understand that this is slightly different from what
> we do for other features that we simply detect and use.
> 
> We do it this way for elision to give distributions the
> flexibility because this feature is quite new and has potential
> side-effects that perhaps might only be best enabled in a newer
> version of the distribution.
> 
> It also gives users the ability to disable it if it's causing
> problems for applications that are important to their use
> cases, but that don't work well with elision.
> 
> In the long term I expect that runtime tunnables will be useful
> in enabling or disabling elision on a per-application basis.
> 
> OK to commit for s390?

For s390 the change is not required.  For Glibc builds without lock elision we do not even want the
variable check in the pthread code.  So we do not even define DO_ELISION if ENABLE_LOCK_ELISION
isn't there (see force-elision.h). Perhaps it makes sense to do the same for x86?

Bye,

-Andreas-

> 
> 2014-09-29  Carlos O'Donell  <carlos@redhat.com>
> 
> 	* configure.ac: --enable-lock-elision enables or disables
> 	all elision for locks, not just mutexes.
> 	* configure: Regenerate.
> 	* sysdeps/unix/sysv/linux/s390/elision-conf.c (elision_init)
> 	[!ENABLE_LOCK_ELISION]: Set __pthread_force_elision to zero.
> 	* sysdeps/unix/sysv/linux/x86/elision-conf.c (elision_init)
> 	[!ENABLE_LOCK_ELISION]: Set __pthread_force_elision,
> 	__elision_available, and __elision_aconf.retry_try_xbegin to zero.
> 
> diff --git a/configure b/configure
> index 89566c5..9a9cf08 100755
> --- a/configure
> +++ b/configure
> @@ -1413,7 +1413,7 @@ Optional Features:
>                            initialize __stack_chk_guard canary with a random
>                            number at program start
>    --enable-lock-elision=yes/no
> -                          Enable lock elision for pthread mutexes by default
> +                          Enable hardware lock elision by default
>    --enable-add-ons[=DIRS...]
>                            configure and build add-ons in DIR1,DIR2,... search
>                            for add-ons if no parameter given
> diff --git a/configure.ac b/configure.ac
> index 82d0896..d113772 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -169,7 +169,7 @@ fi
>  
>  AC_ARG_ENABLE([lock-elision],
>  	      AC_HELP_STRING([--enable-lock-elision[=yes/no]],
> -			     [Enable lock elision for pthread mutexes by default]),
> +			     [Enable hardware lock elision by default]),
>  	      [enable_lock_elision=$enableval],
>  	      [enable_lock_elision=no])
>  AC_SUBST(enable_lock_elision)
> diff --git a/sysdeps/unix/sysv/linux/s390/elision-conf.c b/sysdeps/unix/sysv/linux/s390/elision-conf.c
> index 69c0483..852433e 100644
> --- a/sysdeps/unix/sysv/linux/s390/elision-conf.c
> +++ b/sysdeps/unix/sysv/linux/s390/elision-conf.c
> @@ -60,11 +60,16 @@ elision_init (int argc __attribute__ ((unused)),
>  	      char **argv  __attribute__ ((unused)),
>  	      char **environ)
>  {
> +#ifdef ENABLE_LOCK_ELISION
>    /* Set when the CPU and the kernel supports transactional execution.
>       When false elision is never attempted.  */
>    int elision_available = (GLRO (dl_hwcap) & HWCAP_S390_TE) ? 1 : 0;
>  
>    __pthread_force_elision = __libc_enable_secure ? 0 : elision_available;
> +#else
> +  /* This configuration has elision disabled.  */
> +  __pthread_force_elision = 0;
> +#endif
>  }
>  
>  #ifdef SHARED
> diff --git a/sysdeps/unix/sysv/linux/x86/elision-conf.c b/sysdeps/unix/sysv/linux/x86/elision-conf.c
> index 28e48d9..abc42b7 100644
> --- a/sysdeps/unix/sysv/linux/x86/elision-conf.c
> +++ b/sysdeps/unix/sysv/linux/x86/elision-conf.c
> @@ -62,12 +62,17 @@ elision_init (int argc __attribute__ ((unused)),
>  	      char **argv  __attribute__ ((unused)),
>  	      char **environ)
>  {
> -  __elision_available = HAS_RTM;
>  #ifdef ENABLE_LOCK_ELISION
> +  __elision_available = HAS_RTM;
>    __pthread_force_elision = __libc_enable_secure ? 0 : __elision_available;
> -#endif
>    if (!HAS_RTM)
> -    __elision_aconf.retry_try_xbegin = 0; /* Disable elision on rwlocks */
> +    __elision_aconf.retry_try_xbegin = 0; /* Disable elision on rwlocks.  */
> +#else
> +  /* This configuration has elision disabled.  */
> +  __elision_available = 0;
> +  __pthread_force_elision = 0;
> +  __elision_aconf.retry_try_xbegin = 0;
> +#endif
>  }
>  
>  #ifdef SHARED
> ---
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-09-30 12:12 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-29 19:55 [PATCH] Elision, both for s390 and x86_64, should be enabled via --enable-lock-elision=yes Carlos O'Donell
2014-09-29 22:43 ` Andreas Schwab
2014-09-29 23:01   ` Carlos O'Donell
2014-09-30 12:12 ` Andreas Krebbel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).