Re: [PATCH v11 06/16] qspinlock: prolong the stay in the pending bit path

Peter Zijlstra
2014-06-11T10:26:06Z

[-- Attachment #1.1: Type: text/plain, Size: 1475 bytes --]

On Fri, May 30, 2014 at 11:43:52AM -0400, Waiman Long wrote:
> ---
> kernel/locking/qspinlock.c | 18 ++++++++++++++++--
> 1 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
> index fc7fd8c..7f10758 100644
> --- a/kernel/locking/qspinlock.c
> +++ b/kernel/locking/qspinlock.c
> @@ -233,11 +233,25 @@ void queue_spin_lock_slowpath(struct qspinlock *lock, u32 val)
> */
> for (;;) {
> /*
> - * If we observe any contention; queue.
> + * If we observe that the queue is not empty or both
> + * the pending and lock bits are set, queue
> */
> - if (val & ~_Q_LOCKED_MASK)
> + if ((val & _Q_TAIL_MASK) ||
> + (val == (_Q_LOCKED_VAL|_Q_PENDING_VAL)))
> goto queue;
>
> + if (val == _Q_PENDING_VAL) {
> + /*
> + * Pending bit is set, but not the lock bit.
> + * Assuming that the pending bit holder is going to
> + * set the lock bit and clear the pending bit soon,
> + * it is better to wait than to exit at this point.
> + */
> + cpu_relax();
> + val = atomic_read(&lock->val);
> + continue;
> + }
> +
> new = _Q_LOCKED_VAL;
> if (val == new)
> new |= _Q_PENDING_VAL;

So, again, you just posted a new version without replying to the
previous discussion; so let me try again, what's wrong with the proposal
here:

lkml.kernel.org/r/20140417163640.GT11096@twins.programming.kicks-ass.net

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 183 bytes --]

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org