Re: page_waitqueue() considered harmful

[Peter Zijlstra <peterz@infradead.org>]

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)
> > > 
> > > If this was memory ops to different words, it would require smp_mb each
> > > side.. Being the same word, can we avoid them?   
> > 
> > Ah, that is the reason I put that smp_mb__after_atomic() there. You have
> > a cute point on them being to the same word though. Need to think about
> > that.
> 
> This is all assuming the store accesses are ordered, which you should get
> if the stores to the different bits operate on the same address and size.
> That might not be the case for some architectures, but they might not
> require barriers for other reasons. That would call for an smp_mb variant
> that is used for bitops on different bits but same aligned long. 

Since the {set,clear}_bit operations are atomic, they must be ordered
against one another. The subsequent test_bit is a load, which, since its
to the same variable, and a CPU must appear to preserve Program-Order,
must come after the RmW.

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.

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