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 v10 6/7] locking/pvqspinlock: Allow limited lock stealing
Date: Tue, 10 Nov 2015 14:46:43 -0500 [thread overview]
Message-ID: <564249A3.3070901@hpe.com> (raw)
In-Reply-To: <20151110160343.GE17308@twins.programming.kicks-ass.net>
On 11/10/2015 11:03 AM, Peter Zijlstra wrote:
> On Mon, Nov 09, 2015 at 07:09:26PM -0500, Waiman Long wrote:
>> @@ -291,7 +292,7 @@ static __always_inline void __pv_wait_head(struct qspinlock *lock,
>> void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val)
>> {
>> struct mcs_spinlock *prev, *next, *node;
>> - u32 new, old, tail;
>> + u32 new, old, tail, locked;
>> int idx;
>>
>> BUILD_BUG_ON(CONFIG_NR_CPUS>= (1U<< _Q_TAIL_CPU_BITS));
>> @@ -431,11 +432,25 @@ queue:
>> * sequentiality; this is because the set_locked() function below
>> * does not imply a full barrier.
>> *
>> + * The PV pv_wait_head_or_lock function, if active, will acquire
>> + * the lock and return a non-zero value. So we have to skip the
>> + * smp_load_acquire() call. As the next PV queue head hasn't been
>> + * designated yet, there is no way for the locked value to become
>> + * _Q_SLOW_VAL. So both the set_locked() and the
>> + * atomic_cmpxchg_relaxed() calls will be safe.
>> + *
>> + * If PV isn't active, 0 will be returned instead.
>> + *
>> */
>> - pv_wait_head(lock, node);
>> - while ((val = smp_load_acquire(&lock->val.counter))& _Q_LOCKED_PENDING_MASK)
>> + locked = val = pv_wait_head_or_lock(lock, node);
>> + if (locked)
>> + goto reset_tail_or_wait_next;
>> +
>> + while ((val = smp_load_acquire(&lock->val.counter))
>> + & _Q_LOCKED_PENDING_MASK)
>> cpu_relax();
>>
>> +reset_tail_or_wait_next:
>> /*
>> * claim the lock:
>> *
>> @@ -447,8 +462,12 @@ queue:
>> * to grab the lock.
>> */
>> for (;;) {
>> - if (val != tail) {
>> - set_locked(lock);
>> + /*
>> + * The lock value may or may not have the _Q_LOCKED_VAL bit set.
>> + */
>> + if ((val& _Q_TAIL_MASK) != tail) {
>> + if (!locked)
>> + set_locked(lock);
>> break;
>> }
>> /*
> How about this instead? If we've already got _Q_LOCKED_VAL set, issuing
> that store again isn't much of a problem, the cacheline is already hot
> and we own it and its a regular store not an atomic.
>
> @@ -432,10 +433,13 @@ void queued_spin_lock_slowpath(struct qs
> * does not imply a full barrier.
> *
> */
> - pv_wait_head(lock, node);
> + if ((val = pv_wait_head_or_lock(lock, node)))
> + goto locked;
> +
> while ((val = smp_load_acquire(&lock->val.counter))& _Q_LOCKED_PENDING_MASK)
> cpu_relax();
>
> +locked:
> /*
> * claim the lock:
> *
> @@ -447,7 +451,8 @@ void queued_spin_lock_slowpath(struct qs
> * to grab the lock.
> */
> for (;;) {
> - if (val != tail) {
> + /* In the PV case we might already have _Q_LOCKED_VAL set */
> + if ((val& _Q_TAIL_MASK) != tail) {
> set_locked(lock);
> break;
> }
>
That is certainly fine. I was doing that originally, but then change it
to add an additional if.
BTW, I have a process question. Should I just resend the patch 6 or
should I resend the whole series? I do have a couple of bugs in the
(_Q_PENDING_BITS != 8) part of the patch that I need to fix too.
Cheers,
Longman
next prev parent reply other threads:[~2015-11-10 19:47 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:locking/core] locking/qspinlock: Prefetch the " tip-bot for Waiman Long
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 [this message]
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=564249A3.3070901@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 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.