Mel Gorman <mgorman@xxxxxxx> wrote: > On Thu, Jul 27, 2017 at 04:40:15AM -0700, Nadav Amit wrote: >> Reading tlb_flush_pending while the page-table lock is taken does not >> require a barrier, since the lock/unlock already acts as a barrier. >> Removing the barrier in mm_tlb_flush_pending() to address this issue. >> >> However, migrate_misplaced_transhuge_page() calls mm_tlb_flush_pending() >> while the page-table lock is already released, which may present a >> problem on architectures with weak memory model (PPC). To deal with this >> case, a new parameter is added to mm_tlb_flush_pending() to indicate >> if it is read without the page-table lock taken, and calling >> smp_mb__after_unlock_lock() in this case. >> >> Signed-off-by: Nadav Amit <namit@xxxxxxxxxx> > > Conditional locking based on function arguements are often considered > extremely hazardous. Conditional barriers are even more troublesome because > it's simply too easy to get wrong. > > Revert b0943d61b8fa420180f92f64ef67662b4f6cc493 instead of this patch. It's > not a clean revert but conflicts are due to comment changes. It moves > the check back under the PTL and the impact is marginal given that > it a spurious TLB flush will only occur when potentially racing with > change_prot_range. Since that commit went in, a lot of changes have happened > that alter the scan rate of automatic NUMA balancing so it shouldn't be a > serious issue. It's certainly a nicer option than using conditional barriers. Ok. Initially, I added a memory barrier only in migrate_misplaced_transhuge_page(), and included a detailed comment about it - I still think it is better. But since you feel confident the impact will be relatively small, I will do the revert. -- 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
