public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Noah Goldstein <goldstein.w.n@gmail.com>
Cc: libc-alpha@sourceware.org, carlos@systemhalted.org
Subject: Re: [PATCH v1] nptl: Add single-threaded optimization to ADAPTIVE_NP mutex
Date: Wed, 19 Apr 2023 08:41:33 -0700	[thread overview]
Message-ID: <CAMe9rOrj2gwzt=xeihfNMajh_NqxvtCr4NbCrmmvtsYxg=a=vA@mail.gmail.com> (raw)
In-Reply-To: <20230419011722.1154501-1-goldstein.w.n@gmail.com>

On Tue, Apr 18, 2023 at 6:17 PM Noah Goldstein <goldstein.w.n@gmail.com> wrote:
>
> ADAPTIVED_NP mutex is generally the most performant mutex option and
> is commonly used so it seems preferable for it to also benefit from
> the optimization.

Adaptive mutex works better than normal mutex when futex syscall is the main
bottleneck.   For single threaded applications or machines with fewer cores,
adaptive mutex may not improve performance.   If it is the case, shouldn't we
focus on improving performance when futex syscall is the bottleneck?

> make check passes on linux-x86_64
> ---
>  nptl/pthread_mutex_cond_lock.c |  1 +
>  nptl/pthread_mutex_lock.c      | 40 ++++++++++++++++++++++++++--------
>  2 files changed, 32 insertions(+), 9 deletions(-)
>
> diff --git a/nptl/pthread_mutex_cond_lock.c b/nptl/pthread_mutex_cond_lock.c
> index f3af514305..fcc90bb16c 100644
> --- a/nptl/pthread_mutex_cond_lock.c
> +++ b/nptl/pthread_mutex_cond_lock.c
> @@ -3,6 +3,7 @@
>  #define LLL_MUTEX_LOCK(mutex) \
>    lll_cond_lock ((mutex)->__data.__lock, PTHREAD_MUTEX_PSHARED (mutex))
>  #define LLL_MUTEX_LOCK_OPTIMIZED(mutex) LLL_MUTEX_LOCK (mutex)
> +#define LLL_MUTEX_TRYLOCK_OPTIMIZED(mutex) LLL_MUTEX_TRYLOCK (mutex)
>
>  /* Not actually elided so far. Needed? */
>  #define LLL_MUTEX_LOCK_ELISION(mutex)  \
> diff --git a/nptl/pthread_mutex_lock.c b/nptl/pthread_mutex_lock.c
> index d4f96c70ef..011bd7488d 100644
> --- a/nptl/pthread_mutex_lock.c
> +++ b/nptl/pthread_mutex_lock.c
> @@ -30,9 +30,9 @@
>  /* Some of the following definitions differ when pthread_mutex_cond_lock.c
>     includes this file.  */
>  #ifndef LLL_MUTEX_LOCK
> -/* lll_lock with single-thread optimization.  */
> -static inline void
> -lll_mutex_lock_optimized (pthread_mutex_t *mutex)
> +
> +static inline int
> +lll_mutex_try_singlethreaded_opt (pthread_mutex_t *mutex, int private)
>  {
>    /* The single-threaded optimization is only valid for private
>       mutexes.  For process-shared mutexes, the mutex could be in a
> @@ -41,16 +41,38 @@ lll_mutex_lock_optimized (pthread_mutex_t *mutex)
>       acquired, POSIX requires that pthread_mutex_lock deadlocks for
>       normal mutexes, so skip the optimization in that case as
>       well.  */
> -  int private = PTHREAD_MUTEX_PSHARED (mutex);
>    if (private == LLL_PRIVATE && SINGLE_THREAD_P && mutex->__data.__lock == 0)
> -    mutex->__data.__lock = 1;
> -  else
> +    {
> +      mutex->__data.__lock = 1;
> +      return 0;
> +    }
> +  return 1;
> +}
> +
> +/* lll_trylock with single-thread optimization.  */
> +static inline int
> +lll_mutex_trylock_optimized (pthread_mutex_t *mutex)
> +{
> +  if (lll_mutex_try_singlethreaded_opt (mutex, PTHREAD_MUTEX_PSHARED (mutex))
> +      == 0)
> +    return 0;
> +  return lll_trylock (mutex->__data.__lock);
> +}
> +
> +/* lll_lock with single-thread optimization.  */
> +static inline void
> +lll_mutex_lock_optimized (pthread_mutex_t *mutex)
> +{
> +  int private = PTHREAD_MUTEX_PSHARED (mutex);
> +  if (lll_mutex_try_singlethreaded_opt (mutex, private))
>      lll_lock (mutex->__data.__lock, private);
>  }
>
>  # define LLL_MUTEX_LOCK(mutex)                                         \
>    lll_lock ((mutex)->__data.__lock, PTHREAD_MUTEX_PSHARED (mutex))
>  # define LLL_MUTEX_LOCK_OPTIMIZED(mutex) lll_mutex_lock_optimized (mutex)
> +# define LLL_MUTEX_TRYLOCK_OPTIMIZED(mutex) \
> +  lll_mutex_trylock_optimized (mutex)
>  # define LLL_MUTEX_TRYLOCK(mutex) \
>    lll_trylock ((mutex)->__data.__lock)
>  # define LLL_ROBUST_MUTEX_LOCK_MODIFIER 0
> @@ -133,11 +155,11 @@ PTHREAD_MUTEX_LOCK (pthread_mutex_t *mutex)
>    else if (__builtin_expect (PTHREAD_MUTEX_TYPE (mutex)
>                           == PTHREAD_MUTEX_ADAPTIVE_NP, 1))
>      {
> -      if (LLL_MUTEX_TRYLOCK (mutex) != 0)
> +      if (LLL_MUTEX_TRYLOCK_OPTIMIZED (mutex) != 0)
>         {
>           int cnt = 0;
> -         int max_cnt = MIN (max_adaptive_count (),
> -                            mutex->__data.__spins * 2 + 10);
> +         int max_cnt
> +             = MIN (max_adaptive_count (), mutex->__data.__spins * 2 + 10);
>           int spin_count, exp_backoff = 1;
>           unsigned int jitter = get_jitter ();
>           do
> --
> 2.34.1
>


-- 
H.J.

  reply	other threads:[~2023-04-19 15:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-19  1:17 Noah Goldstein
2023-04-19 15:41 ` H.J. Lu [this message]
2023-04-19 16:57   ` Noah Goldstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMe9rOrj2gwzt=xeihfNMajh_NqxvtCr4NbCrmmvtsYxg=a=vA@mail.gmail.com' \
    --to=hjl.tools@gmail.com \
    --cc=carlos@systemhalted.org \
    --cc=goldstein.w.n@gmail.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).