Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1246017

Re: [PATCH v7 1/5] locking/qspinlock: relaxes cmpxchg & xchg ops in native code

From Peter Zijlstra <peterz@infradead.org>
Newsgroups linux.kernel
Subject Re: [PATCH v7 1/5] locking/qspinlock: relaxes cmpxchg & xchg ops in native code
Date 2015-10-13 20:10 +0200
Message-ID <qjcbq-5SM-39@gated-at.bofh.it> (permalink)
References <qbCPn-8bs-3@gated-at.bofh.it> <qbCPn-8bs-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Tue, Sep 22, 2015 at 04:50:40PM -0400, Waiman Long wrote:
> This patch replaces the cmpxchg() and xchg() calls in the native
> qspinlock code with more relaxed versions of those calls to enable
> other architectures to adopt queued spinlocks with less performance
> overhead.

> @@ -62,7 +63,7 @@ static __always_inline int queued_spin_is_contended(struct qspinlock *lock)
>  static __always_inline int queued_spin_trylock(struct qspinlock *lock)
>  {
>  	if (!atomic_read(&lock->val) &&
> -	   (atomic_cmpxchg(&lock->val, 0, _Q_LOCKED_VAL) == 0))
> +	   (atomic_cmpxchg_acquire(&lock->val, 0, _Q_LOCKED_VAL) == 0))
>  		return 1;
>  	return 0;
>  }
> @@ -77,7 +78,7 @@ static __always_inline void queued_spin_lock(struct qspinlock *lock)
>  {
>  	u32 val;
>  
> -	val = atomic_cmpxchg(&lock->val, 0, _Q_LOCKED_VAL);
> +	val = atomic_cmpxchg_acquire(&lock->val, 0, _Q_LOCKED_VAL);
>  	if (likely(val == 0))
>  		return;
>  	queued_spin_lock_slowpath(lock, val);

> @@ -319,7 +329,7 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val)
>  		if (val == new)
>  			new |= _Q_PENDING_VAL;
>  
> -		old = atomic_cmpxchg(&lock->val, val, new);
> +		old = atomic_cmpxchg_acquire(&lock->val, val, new);
>  		if (old == val)
>  			break;
>  

So given recent discussion, all this _release/_acquire stuff is starting
to worry me.

So we've not declared if they should be RCsc or RCpc, and given this
patch (and the previous ones) these lock primitives turn into RCpc if
the atomic primitives are RCpc.

So far only the proposed PPC implementation is RCpc -- and their current
spinlock implementation is also RCpc, but that is a point of discussion.

Just saying..

Also, I think we should annotate the control dependencies in these
things.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextNext in thread | Find similar | Unroll thread


Thread

Re: [PATCH v7 1/5] locking/qspinlock: relaxes cmpxchg & xchg ops in  native code Peter Zijlstra <peterz@infradead.org> - 2015-10-13 20:10 +0200
  Re: [PATCH v7 1/5] locking/qspinlock: relaxes cmpxchg & xchg ops  in native code Waiman Long <waiman.long@hpe.com> - 2015-10-13 22:40 +0200
    Re: [PATCH v7 1/5] locking/qspinlock: relaxes cmpxchg & xchg ops in  native code Peter Zijlstra <peterz@infradead.org> - 2015-10-13 22:50 +0200
  Re: [PATCH v7 1/5] locking/qspinlock: relaxes cmpxchg & xchg ops in  native code Will Deacon <will.deacon@arm.com> - 2015-10-14 11:40 +0200

csiph-web