On 09/05/2017 09:20 PM, Mel Gorman wrote: > On Tue, Sep 05, 2017 at 08:15:40PM +0530, Anshuman Khandual wrote: >> The entire scheme of deferred TLB flush in reclaim path rests on the >> fact that the cost to refill TLB entries is less than flushing out >> individual entries by sending IPI to remote CPUs. But architecture >> can have different ways to evaluate that. Hence apart from checking >> TTU_BATCH_FLUSH in the TTU flags, rest of the decision should be >> architecture specific. >> >> Signed-off-by: Anshuman Khandual <khandual@xxxxxxxxxxxxxxxxxx> > > There is only one arch implementation given and if an arch knows that > the flush should not be deferred then why would it implement support in > the first place? I'm struggling to see the point of the patch. Even if the arch supports deferring of TLB flush like in the existing case, it still checks if mm_cpumask(mm) contains anything other than the current CPU (which indicates need for an IPI for a TLB flush) to decide whether the TLB batch flush should be deferred or not. The point is some architectures might do something different for a given struct mm other than checking for presence of remote CPU in the mask mm_cpumask(mm). It might be specific to the situation, struct mm etc. Hence arch callback should be used instead. -- 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>
