On Wed, Sep 28, 2016 at 04:05:30AM -0700, Paul E. McKenney wrote: > On Wed, Sep 28, 2016 at 09:05:46AM +0200, Peter Zijlstra wrote: > > On Wed, Sep 28, 2016 at 03:06:21AM +1000, Nicholas Piggin wrote: > > > On Tue, 27 Sep 2016 18:52:21 +0200 > > > Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > > > > > On Wed, Sep 28, 2016 at 12:53:18AM +1000, Nicholas Piggin wrote: > > > > > The more interesting is the ability to avoid the barrier between fastpath > > > > > clearing a bit and testing for waiters. > > > > > > > > > > unlock(): lock() (slowpath): > > > > > clear_bit(PG_locked) set_bit(PG_waiter) > > > > > test_bit(PG_waiter) test_bit(PG_locked) > > The point being that at least one of the test_bit() calls must return > true? Yes, more or less. Either unlock() observes PG_waiters set, or lock() observes PG_locked unset. (opposed to all our 'normal' examples the initial state isn't all 0 and the stores aren't all 1 :-). > As far as I know, all architectures fully order aligned same-size > machine-sized accesses to the same location even without barriers. > In the example above, the PG_locked and PG_waiter are different bits in > the same location, correct? (Looks that way, but the above also looks > a bit abbreviated.) Correct, PG_* all live in the same word. > So unless they operate on the same location or are accompanied by > something like the smp_mb__after_atomic() called out above, there > is no ordering. Same word.. > > So I think you're right and that we can forgo the memory barriers here. > > I even think this must be true on all architectures. > > > > Paul and Alan have a validation tool someplace, put them on Cc. > > It does not yet fully handle atomics yet (but maybe Alan is ahead of > me here, in which case he won't be shy). However, the point about > strong ordering of same-sized aligned accesses to a machine-sized > location can be made without atomics: Great. That's what I remember from reading that stuff. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>