Thread (42 messages) 42 messages, 9 authors, 2016-10-03

Re: page_waitqueue() considered harmful

From: Nicholas Piggin <npiggin@gmail.com>
Date: 2016-09-29 06:42:39

On Thu, 29 Sep 2016 08:21:32 +0200
Peter Zijlstra [off-list ref] wrote:
On Thu, Sep 29, 2016 at 11:31:32AM +1000, Nicholas Piggin wrote:
quoted
quoted
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.  
In generic code, I don't think so. We'd need an
smp_mb__between_bitops_to_the_same_aligned_long, wouldn't we?

x86 implements set_bit as 'orb (addr),bit_nr', and compiler could
implement test_bit as a byte load as well. If those bits are in
different bytes, then they could be reordered, no?

ia64 does 32-bit ops. If you make PG_waiter 64-bit only and put it
in the different side of the long, then this could be a problem too.  
Not on ia64, its atomics are full barriers too, just like x86 (even
though its docs imply otherwise). But I get the point.
Oh yes of course I knew x86 atomics were barriers :)

Take Alpha instead. It's using 32-bit ops.
I would however rather audit and attempt to fix affected archs before
introducing such a barrier if at all possible.
--
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>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help