public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Kemi Wang <kemi.wang@intel.com>
To: Glibc alpha <libc-alpha@sourceware.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
	Tim Chen <tim.c.chen@intel.com>,
	Andi Kleen <andi.kleen@intel.com>,
	Ying Huang <ying.huang@intel.com>, Aaron Lu <aaron.lu@intel.com>,
	Lu Aubrey <aubrey.li@intel.com>, Kemi Wang <kemi.wang@intel.com>
Subject: [PATCH 3/3] Mutex: Avoid useless spinning
Date: Fri, 30 Mar 2018 07:17:00 -0000	[thread overview]
Message-ID: <1522394093-9835-3-git-send-email-kemi.wang@intel.com> (raw)
In-Reply-To: <1522394093-9835-1-git-send-email-kemi.wang@intel.com>

Usually, we can't set too short time out while spinning on the lock, that
probably makes a thread which is trying to acquire the lock go to sleep
quickly, thus weakens the benefit of pthread adaptive spin lock.

However, there is also a problem if we set the time out large in
case of protecting a small critical section with severe lock contention.
As we can see the test result in the last patch, the performance is highly
effected by the spin count tunables, smaller spin count, better performance
improvement. This is because the thread probably spins on the lock until
timeout in severe lock contention before going to sleep.

In this patch, we avoid the useless spin by making the spinner sleep
if it fails to acquire the lock when the lock is available, as suggested
by Tim Chen.

nr_threads    base       COUNT=1000(head~1)   COUNT=1000(head)
1           51644585      51323778(-0.6%)	     51378551(-0.5%)
2           7914789       9867343(+24.7%)	     11503559(+45.3%)
7           1687620       3430504(+103.3%)	     7817383(+363.2%)
14          1026555       1843458(+79.6%)	     7360883(+617.0%)
28          962001        681965(-29.1%)	     5681945(+490.6%)
56          883770        364879(-58.7%)	     3416068(+286.5%)
112         1150589       415261(-63.9%)	     3255700(+183.0%)

Suggested-by: Tim Chen <tim.c.chen@intel.com>
Signed-off-by: Kemi Wang <kemi.wang@intel.com>
---
 nptl/pthread_mutex_lock.c | 25 +++++++++++--------------
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/nptl/pthread_mutex_lock.c b/nptl/pthread_mutex_lock.c
index c3aca93..0faee1a 100644
--- a/nptl/pthread_mutex_lock.c
+++ b/nptl/pthread_mutex_lock.c
@@ -127,22 +127,19 @@ __pthread_mutex_lock (pthread_mutex_t *mutex)
 	  int cnt = 0;
 	  int max_cnt = MIN (__mutex_aconf.spin_count,
 			mutex->__data.__spins * 2 + 100);
+
+     	/* MO read while spinning */
 	  do
-	    {
-		if (cnt >= max_cnt)
-		  {
-		    LLL_MUTEX_LOCK (mutex);
-		    break;
-		  }
-		/* MO read while spinning */
-		do
-		  {
-		    atomic_spin_nop ();
-		  }
-		while (atomic_load_relaxed (&mutex->__data.__lock) != 0 &&
+    	{
+		  atomic_spin_nop ();
+		}
+	  while (atomic_load_relaxed (&mutex->__data.__lock) != 0 &&
 			++cnt < max_cnt);
-	    }
-	  while (LLL_MUTEX_TRYLOCK (mutex) != 0);
+	    /* Try to acquire the lock if lock is available or the spin count
+	     * is run out, go to sleep if fails
+	     */
+	  if (LLL_MUTEX_TRYLOCK (mutex) != 0)
+		  LLL_MUTEX_LOCK (mutex);
 
 	  mutex->__data.__spins += (cnt - mutex->__data.__spins) / 8;
 	}
-- 
2.7.4

  reply	other threads:[~2018-03-30  7:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-30  7:17 [PATCH 1/3] Tunables: Add tunables of spin count for adaptive spin mutex Kemi Wang
2018-03-30  7:17 ` Kemi Wang [this message]
2018-04-05 20:59   ` [PATCH 3/3] Mutex: Avoid useless spinning Adhemerval Zanella
2018-04-08  8:33     ` kemi
2018-03-30  7:17 ` [PATCH 2/3] Mutex: Only read while spinning Kemi Wang
2018-04-05 20:55   ` Adhemerval Zanella
2018-04-08  8:30     ` kemi
2018-04-09 20:52       ` Adhemerval Zanella
2018-04-10  1:49         ` kemi
2018-04-11 13:28           ` Adhemerval Zanella
2018-04-02 15:19 ` [PATCH 1/3] Tunables: Add tunables of spin count for adaptive spin mutex Adhemerval Zanella
2018-04-04 10:27 ` kemi
2018-04-04 17:17   ` Adhemerval Zanella
2018-04-05  1:11     ` Carlos O'Donell

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=1522394093-9835-3-git-send-email-kemi.wang@intel.com \
    --to=kemi.wang@intel.com \
    --cc=aaron.lu@intel.com \
    --cc=andi.kleen@intel.com \
    --cc=aubrey.li@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=libc-alpha@sourceware.org \
    --cc=tim.c.chen@intel.com \
    --cc=ying.huang@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 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).