On Fri, Dec 15, 2023 at 12:48:10AM -0800, Jianfeng Wang wrote: > On 12/14/23 3:00 PM, Matthew Wilcox wrote: > > Shouldn't we put this in __tlb_gather_mmu() which already has the > > CONFIG_MMU_GATHER_NO_GATHER ifdefs? That would presuambly help with, eg > > zap_page_range_single() too. > > After looking at different use cases of tlb_gather_mmu(), I feel it is > questionable to move lru_add_drain() into __tlb_gather_mmu(). There are > two use cases of tlb_gather_mmu(): one for unmapping and releasing pages > (e.g., the two cases in mmap.c); the other one is to update page table > entries and flush TLB without releasing pages (e.g., together with > mprotect_fixup()). For the latter use case, it is reasonable to not call > lru_add_drain() prior to or within tlb_gather_mmu(). > > Of course, we may update tlb_gather_mmu()'s API to take this into account. > For example, we can have tlb_gather_mmu_for_release() for the first case > and tlb_gather_mmu() for the latter. I'd like to have your opinion on this. Yes, I like this idea. You're right that there's no need to drain the lru lists for the other use case, so it makes sense to have two APIs.
