From: "Long, Wai Man" <waiman.long@hp.com>
To: Jason Low <jason.low2@hp.com>,
mingo@kernel.org, peterz@infradead.org, tglx@linutronix.de,
akpm@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, tim.c.chen@linux.intel.com,
paulmck@linux.vnet.ibm.com, rostedt@goodmis.org,
davidlohr@hp.com, scott.norton@hp.com, aswin@hp.com
Subject: Re: [PATCH v2 2/4] mutex: Delete the MUTEX_SHOW_NO_WAITER macro
Date: Wed, 11 Jun 2014 21:27:25 -0400 [thread overview]
Message-ID: <539901FD.2020101@hp.com> (raw)
In-Reply-To: <1402511843-4721-3-git-send-email-jason.low2@hp.com>
On 6/11/2014 2:37 PM, Jason Low wrote:
> v1->v2:
> - There were discussions in v1 about a possible mutex_has_waiters()
> function. This patch didn't use that function because the places which
> used MUTEX_SHOW_NO_WAITER requires checking for lock->count while an
> actual mutex_has_waiters() should check for !list_empty(wait_list).
> We'll just delete the macro and directly use atomic_read() + comments.
>
> MUTEX_SHOW_NO_WAITER() is a macro which checks for if there are
> "no waiters" on a mutex by checking if the lock count is non-negative.
> Based on feedback from the discussion in the earlier version of this
> patchset, the macro is not very readable.
>
> Furthermore, checking lock->count isn't always the correct way to
> determine if there are "no waiters" on a mutex. For example, a negative
> count on a mutex really only means that there "potentially" are
> waiters. Likewise, there can be waiters on the mutex even if the count is
> non-negative. Thus, "MUTEX_SHOW_NO_WAITER" doesn't always do what the name
> of the macro suggests.
>
> So this patch deletes the MUTEX_SHOW_NO_WAITERS() macro, directly
> use atomic_read() instead of the macro, and adds comments which
> elaborate on how the extra atomic_read() checks can help reduce
> unnecessary xchg() operations.
>
> Signed-off-by: Jason Low <jason.low2@hp.com>
> ---
> kernel/locking/mutex.c | 18 ++++++++----------
> 1 files changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> index dd26bf6..4bd9546 100644
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -46,12 +46,6 @@
> # include <asm/mutex.h>
> #endif
>
> -/*
> - * A negative mutex count indicates that waiters are sleeping waiting for the
> - * mutex.
> - */
> -#define MUTEX_SHOW_NO_WAITER(mutex) (atomic_read(&(mutex)->count) >= 0)
> -
> void
> __mutex_init(struct mutex *lock, const char *name, struct lock_class_key *key)
> {
> @@ -483,8 +477,11 @@ slowpath:
> #endif
> spin_lock_mutex(&lock->wait_lock, flags);
>
> - /* once more, can we acquire the lock? */
> - if (MUTEX_SHOW_NO_WAITER(lock) && (atomic_xchg(&lock->count, 0) == 1))
> + /*
> + * Once more, try to acquire the lock. Only try-lock the mutex if
> + * lock->count >= 0 to reduce unnecessary xchg operations.
> + */
> + if (atomic_read(&lock->count) >= 0 && (atomic_xchg(&lock->count, 0) == 1))
> goto skip_wait;
>
> debug_mutex_lock_common(lock, &waiter);
> @@ -504,9 +501,10 @@ slowpath:
> * it's unlocked. Later on, if we sleep, this is the
> * operation that gives us the lock. We xchg it to -1, so
> * that when we release the lock, we properly wake up the
> - * other waiters:
> + * other waiters. We only attempt the xchg if the count is
> + * non-negative in order to avoid unnecessary xchg operations:
> */
> - if (MUTEX_SHOW_NO_WAITER(lock) &&
> + if (atomic_read(&lock->count) >= 0 &&
> (atomic_xchg(&lock->count, -1) == 1))
> break;
>
Acked-by: Waiman Long <Waiman.Long@hp.com>
next prev parent reply other threads:[~2014-06-12 1:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-11 18:37 [PATCH v2 0/4] mutex: Modifications to mutex Jason Low
2014-06-11 18:37 ` [PATCH v2 1/4] mutex: Correct documentation on mutex optimistic spinning Jason Low
2014-07-05 10:47 ` [tip:locking/core] locking/mutexes: " tip-bot for Jason Low
2014-06-11 18:37 ` [PATCH v2 2/4] mutex: Delete the MUTEX_SHOW_NO_WAITER macro Jason Low
2014-06-12 1:27 ` Long, Wai Man [this message]
2014-07-05 10:47 ` [tip:locking/core] locking/mutexes: " tip-bot for Jason Low
2014-06-11 18:37 ` [PATCH v2 3/4] mutex: Try to acquire mutex only if it is unlocked Jason Low
2014-06-12 1:28 ` Long, Wai Man
2014-06-12 19:37 ` Davidlohr Bueso
2014-06-12 19:54 ` Jason Low
2014-07-05 10:47 ` [tip:locking/core] locking/mutexes: " tip-bot for Jason Low
2014-06-11 18:37 ` [PATCH v2 4/4] mutex: Optimize mutex trylock slowpath Jason Low
2014-06-12 18:25 ` Davidlohr Bueso
2014-07-05 10:48 ` [tip:locking/core] locking/mutexes: " tip-bot for Jason Low
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=539901FD.2020101@hp.com \
--to=waiman.long@hp.com \
--cc=akpm@linux-foundation.org \
--cc=aswin@hp.com \
--cc=davidlohr@hp.com \
--cc=jason.low2@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=scott.norton@hp.com \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.