Re: [RFC PATCH-tip v2 1/6] locking/osq: Make lock/unlock proper acquire/release barrier

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/16/2016 09:11 PM, Davidlohr Bueso wrote:
On Wed, 15 Jun 2016, Peter Zijlstra wrote:

Yeah, see a few patches further in this series, where he guards a
variables with the osq_lock.

So one problem I have with all this is that if we are hardening osq_lock/unlock() because of some future use that is specific to rwsems, then we will immediately
be hurting mutexes for no good reason.


I am going to change it to use smp_acquire__after_ctrl_dep() as suggested by PeterZ. Is that a good enough compromise? I have also changed the xchg in the unlock side to xchg_release which could help performance in some archs. The thing is when developers see the name osq_lock/osq_unlock, they will naturally assume the proper barrriers are provided which is not currently the case.

Anyway, the change won't affect x86, it is probably ARM or PPC that may have an impact.

Cheers,
Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux