public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: tip-bot for Waiman Long <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: tglx@linutronix.de, scott.norton@hpe.com, Waiman.Long@hpe.com,
	mingo@kernel.org, linux-kernel@vger.kernel.org,
	paulmck@linux.vnet.ibm.com, torvalds@linux-foundation.org,
	akpm@linux-foundation.org, peterz@infradead.org,
	doug.hatch@hpe.com, hpa@zytor.com, dave@stgolabs.net
Subject: [tip:locking/core] locking/qspinlock: Prefetch the next node cacheline
Date: Mon, 23 Nov 2015 08:27:13 -0800	[thread overview]
Message-ID: <tip-81b5598665a24083dd889fbd8cb08b0d8de4b8ad@git.kernel.org> (raw)
In-Reply-To: <1447114167-47185-3-git-send-email-Waiman.Long@hpe.com>

Commit-ID:  81b5598665a24083dd889fbd8cb08b0d8de4b8ad
Gitweb:     http://git.kernel.org/tip/81b5598665a24083dd889fbd8cb08b0d8de4b8ad
Author:     Waiman Long <Waiman.Long@hpe.com>
AuthorDate: Mon, 9 Nov 2015 19:09:22 -0500
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Mon, 23 Nov 2015 10:01:59 +0100

locking/qspinlock: Prefetch the next node cacheline

A queue head CPU, after acquiring the lock, will have to notify
the next CPU in the wait queue that it has became the new queue
head. This involves loading a new cacheline from the MCS node of the
next CPU. That operation can be expensive and add to the latency of
locking operation.

This patch addes code to optmistically prefetch the next MCS node
cacheline if the next pointer is defined and it has been spinning
for the MCS lock for a while. This reduces the locking latency and
improves the system throughput.

The performance change will depend on whether the prefetch overhead
can be hidden within the latency of the lock spin loop. On really
short critical section, there may not be performance gain at all. With
longer critical section, however, it was found to have a performance
boost of 5-10% over a range of different queue depths with a spinlock
loop microbenchmark.

Signed-off-by: Waiman Long <Waiman.Long@hpe.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Douglas Hatch <doug.hatch@hpe.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott J Norton <scott.norton@hpe.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1447114167-47185-3-git-send-email-Waiman.Long@hpe.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 kernel/locking/qspinlock.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
index 7868418..365b203 100644
--- a/kernel/locking/qspinlock.c
+++ b/kernel/locking/qspinlock.c
@@ -407,6 +407,16 @@ queue:
 
 		pv_wait_node(node);
 		arch_mcs_spin_lock_contended(&node->locked);
+
+		/*
+		 * While waiting for the MCS lock, the next pointer may have
+		 * been set by another lock waiter. We optimistically load
+		 * the next pointer & prefetch the cacheline for writing
+		 * to reduce latency in the upcoming MCS unlock operation.
+		 */
+		next = READ_ONCE(node->next);
+		if (next)
+			prefetchw(next);
 	}
 
 	/*

  reply	other threads:[~2015-11-23 16:28 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-10  0:09 [PATCH tip/locking/core v10 0/7] locking/qspinlock: Enhance qspinlock & pvqspinlock performance Waiman Long
2015-11-10  0:09 ` [PATCH tip/locking/core v10 1/7] locking/qspinlock: Use _acquire/_release versions of cmpxchg & xchg Waiman Long
2015-11-23 16:26   ` [tip:locking/core] locking/qspinlock: Use _acquire/_release() versions of cmpxchg() & xchg() tip-bot for Waiman Long
2015-11-10  0:09 ` [PATCH tip/locking/core v10 2/7] locking/qspinlock: prefetch next node cacheline Waiman Long
2015-11-23 16:27   ` tip-bot for Waiman Long [this message]
2015-11-10  0:09 ` [PATCH tip/locking/core v10 3/7] locking/qspinlock: Avoid redundant read of next pointer Waiman Long
2015-11-23 16:27   ` [tip:locking/core] " tip-bot for Waiman Long
2015-11-10  0:09 ` [PATCH tip/locking/core v10 4/7] locking/pvqspinlock, x86: Optimize PV unlock code path Waiman Long
2015-11-23 16:27   ` [tip:locking/core] locking/pvqspinlock, x86: Optimize the " tip-bot for Waiman Long
2015-11-10  0:09 ` [PATCH tip/locking/core v10 5/7] locking/pvqspinlock: Collect slowpath lock statistics Waiman Long
2015-11-23  9:51   ` Peter Zijlstra
2015-11-25 19:08     ` Waiman Long
2015-12-04 12:00   ` [tip:locking/core] " tip-bot for Waiman Long
2015-11-10  0:09 ` [PATCH tip/locking/core v10 6/7] locking/pvqspinlock: Allow limited lock stealing Waiman Long
2015-11-10 16:03   ` Peter Zijlstra
2015-11-10 19:46     ` Waiman Long
2015-11-10 21:07       ` Peter Zijlstra
2015-11-10  0:09 ` [PATCH tip/locking/core v10 7/7] locking/pvqspinlock: Queue node adaptive spinning Waiman Long
2015-12-04 12:00   ` [tip:locking/core] " tip-bot for Waiman Long

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=tip-81b5598665a24083dd889fbd8cb08b0d8de4b8ad@git.kernel.org \
    --to=tipbot@zytor.com \
    --cc=Waiman.Long@hpe.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave@stgolabs.net \
    --cc=doug.hatch@hpe.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=scott.norton@hpe.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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