Re: page_waitqueue() considered harmful

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Wed, Sep 28, 2016 at 01:16:45PM +0200, Peter Zijlstra wrote:
> 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@infradead.org> 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 :-).

You lost me on unlock() doing any observation, but yes, I transliterated
to standard form, unintentionally, as it turns out.  ;-)

So the goal is that either test_bit(PG_waiter) sees the set_bit()
or test_bit(PG_locked) sees the clear_bit(), correct?

> > 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.

That should make things somewhat more reliable.  ;-)

> > 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.

;-)

							Thanx, Paul

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>