2016-04-22 09:42:54

by Peter Zijlstra

Subject: [RFC][PATCH 31/31] locking,qrwlock: Employ atomic_fetch_add_acquire()

The only reason for the current code is to make GCC emit only the
"LOCK XADD" instruction on x86 (and not do a pointless extra ADD on
the result), do so nicer.

Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
---
kernel/locking/qrwlock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/locking/qrwlock.c
+++ b/kernel/locking/qrwlock.c
@@ -93,7 +93,7 @@ void queued_read_lock_slowpath(struct qr
* that accesses can't leak upwards out of our subsequent critical
* section in the case that the lock is currently held for write.
*/
- cnts = atomic_add_return_acquire(_QR_BIAS, &lock->cnts) - _QR_BIAS;
+ cnts = atomic_fetch_add_acquire(_QR_BIAS, &lock->cnts);
rspin_until_writer_unlock(lock, cnts);

/*

2016-04-22 14:25:23

by Waiman Long

Subject: Re: [RFC][PATCH 31/31] locking,qrwlock: Employ atomic_fetch_add_acquire()

On 04/22/2016 05:04 AM, Peter Zijlstra wrote:
> The only reason for the current code is to make GCC emit only the
> "LOCK XADD" instruction on x86 (and not do a pointless extra ADD on
> the result), do so nicer.
>
> Signed-off-by: Peter Zijlstra (Intel)<[email protected]>
> ---
> kernel/locking/qrwlock.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/kernel/locking/qrwlock.c
> +++ b/kernel/locking/qrwlock.c
> @@ -93,7 +93,7 @@ void queued_read_lock_slowpath(struct qr
> * that accesses can't leak upwards out of our subsequent critical
> * section in the case that the lock is currently held for write.
> */
> - cnts = atomic_add_return_acquire(_QR_BIAS,&lock->cnts) - _QR_BIAS;
> + cnts = atomic_fetch_add_acquire(_QR_BIAS,&lock->cnts);
> rspin_until_writer_unlock(lock, cnts);
>
> /*
>
>

Thanks for taking out this weirdness in the code.

Acked-by: Waiman Long <[email protected]>