On Wed, Dec 11, 2013 at 04:40:52PM +0000, Mel Gorman wrote: > On Wed, Dec 11, 2013 at 06:44:47AM -0800, Paul E. McKenney wrote: > > On Wed, Dec 11, 2013 at 01:21:09PM +0000, Mel Gorman wrote: > > > According to documentation on barriers, stores issued before a LOCK can > > > complete after the lock implying that it's possible tlb_flush_pending can > > > be visible after a page table update. As per revised documentation, this patch > > > adds a smp_mb__before_spinlock to guarantee the correct ordering. > > > > > > Cc: stable@xxxxxxxxxxxxxxx > > > Signed-off-by: Mel Gorman <mgorman@xxxxxxx> > > > > Assuming that there is a lock acquisition after calls to > > set_tlb_flush_pending(): > > > > Acked-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx> > > > > (I don't see set_tlb_flush_pending() in mainline.) > > > > It's introduced by a patch flight that is currently sitting in Andrew's > tree. In the case where we care about the value of tlb_flush_pending, a > spinlock will be taken. PMD or PTE split spinlocks or the mm->page_table_lock > depending on whether it is 3.13 or 3.12-stable and earlier kernels. I > pushed the relevant patches to this tree and branch > > git://git.kernel.org/pub/scm/linux/kernel/git/mel/linux-balancenuma.git numab-instrument-serialise-v5r1 > > There is no guarantee the lock will be taken if there are no pages populated > in the region but we also do not care about flushing the TLB in that case > either. Does it matter that there is no guarantee a lock will be taken > after smp_mb__before_spinlock, just very likely that it will be? If you do smp_mb__before_spinlock() without a lock acquisition, no harm will be done, other than possibly a bit of performance loss. So you should be OK. Thanx, Paul -- 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>