On Wed, Sep 06, 2017 at 09:23:49AM +0530, Anshuman Khandual wrote: > 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. > If that turns out to be the case then the arch can create the hook at the same time. RIght now, this is churn. -- Mel Gorman SUSE Labs -- 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>
