From: Waiman Long <waiman.long@hpe.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Scott J Norton <scott.norton@hpe.com>,
Douglas Hatch <doug.hatch@hpe.com>,
Davidlohr Bueso <dave@stgolabs.net>
Subject: Re: [PATCH tip/locking/core v9 6/6] locking/pvqspinlock: Queue node adaptive spinning
Date: Mon, 09 Nov 2015 11:51:20 -0500 [thread overview]
Message-ID: <5640CF08.2010001@hpe.com> (raw)
In-Reply-To: <20151106203709.GD17308@twins.programming.kicks-ass.net>
On 11/06/2015 03:37 PM, Peter Zijlstra wrote:
> On Fri, Nov 06, 2015 at 12:54:06PM -0500, Waiman Long wrote:
>>>> +static void pv_wait_node(struct mcs_spinlock *node, struct mcs_spinlock *prev)
>>>> {
>>>> struct pv_node *pn = (struct pv_node *)node;
>>>> + struct pv_node *pp = (struct pv_node *)prev;
>>>> int waitcnt = 0;
>>>> int loop;
>>>> + bool wait_early;
>>>>
>>>> /* waitcnt processing will be compiled out if !QUEUED_LOCK_STAT */
>>>> for (;; waitcnt++) {
>>>> - for (loop = SPIN_THRESHOLD; loop; loop--) {
>>>> + for (wait_early = false, loop = SPIN_THRESHOLD; loop; loop--) {
>>>> if (READ_ONCE(node->locked))
>>>> return;
>>>> + if (pv_wait_early(pp, loop)) {
>>>> + wait_early = true;
>>>> + break;
>>>> + }
>>>> cpu_relax();
>>>> }
>>>>
>>> So if prev points to another node, it will never see vcpu_running. Was
>>> that fully intended?
>> I had added code in pv_wait_head_or_lock to set the state appropriately for
>> the queue head vCPU.
> Yes, but that's the head, for nodes we'll always have halted or hashed.
The node state was initialized to be vcpu_running. In pv_wait_node(), it
will be changed to vcpu_halted before sleeping and back to vcpu_running
after that. So it is not true that it is either halted or hashed.
In case, it was changed to vcpu_hashed, it will be changed back to
vcpu_running in pv_wait_head_lock before entering the active spinning
loop. There are definitely a small amount of time where the node state
does not reflect the actual vCPU state, but that is the best we can do
so far.
Cheers,
Longman
next prev parent reply other threads:[~2015-11-09 16:51 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-30 23:26 [PATCH tip/locking/core v9 0/6] locking/qspinlock: Enhance pvqspinlock Waiman Long
2015-10-30 23:26 ` [PATCH tip/locking/core v9 1/6] locking/qspinlock: Use _acquire/_release versions of cmpxchg & xchg Waiman Long
2015-10-30 23:26 ` [PATCH tip/locking/core v9 2/6] locking/qspinlock: prefetch next node cacheline Waiman Long
2015-11-02 16:36 ` Peter Zijlstra
2015-11-02 22:54 ` Peter Zijlstra
2015-11-05 16:42 ` Waiman Long
2015-11-05 16:49 ` Peter Zijlstra
2015-11-05 16:06 ` Waiman Long
2015-11-05 16:39 ` Peter Zijlstra
2015-11-05 16:52 ` Waiman Long
2015-10-30 23:26 ` [PATCH tip/locking/core v9 3/6] locking/pvqspinlock, x86: Optimize PV unlock code path Waiman Long
2015-10-30 23:26 ` [PATCH tip/locking/core v9 4/6] locking/pvqspinlock: Collect slowpath lock statistics Waiman Long
2015-11-02 16:40 ` Peter Zijlstra
2015-11-05 16:29 ` Waiman Long
2015-11-05 16:43 ` Peter Zijlstra
2015-11-05 16:59 ` Waiman Long
2015-11-05 17:09 ` Peter Zijlstra
2015-11-05 17:34 ` Waiman Long
2015-10-30 23:26 ` [PATCH tip/locking/core v9 5/6] locking/pvqspinlock: Allow 1 lock stealing attempt Waiman Long
2015-11-06 14:50 ` Peter Zijlstra
2015-11-06 17:47 ` Waiman Long
2015-11-09 17:29 ` Peter Zijlstra
2015-11-09 19:53 ` Waiman Long
2015-10-30 23:26 ` [PATCH tip/locking/core v9 6/6] locking/pvqspinlock: Queue node adaptive spinning Waiman Long
2015-11-06 15:01 ` Peter Zijlstra
2015-11-06 17:54 ` Waiman Long
2015-11-06 20:37 ` Peter Zijlstra
2015-11-09 16:51 ` Waiman Long [this message]
2015-11-09 17:33 ` Peter Zijlstra
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=5640CF08.2010001@hpe.com \
--to=waiman.long@hpe.com \
--cc=dave@stgolabs.net \
--cc=doug.hatch@hpe.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=scott.norton@hpe.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 NNTP newsgroup(s).