On Thu, May 01, 2014 at 08:34:03AM +0100, Steve Capper wrote: > On Wed, Apr 30, 2014 at 06:21:14PM +0100, Catalin Marinas wrote: > > Both powerpc and sparc use tlb_remove_table() via their __pte_free_tlb() > > etc. which implies an IPI for synchronisation if mm_users > 1. For > > gup_fast we may not need it since we use the RCU for protection. Am I > > missing anything? > > So my understanding is: > > tlb_remove_table will just immediately free any pages where there's a > single user as there's no need to consider a gup walking. Does gup_fast walking increment the mm_users? Or is it a requirement of the calling code? I can't seem to find where this happens. > For the case of multiple users we have an mmu_table_batch structure > that holds references to pages that should be freed at a later point. Yes. > This batch is contained on a page that is allocated on the fly. If, for > any reason, we can't allocate the batch container we fallback to a slow > path which is to issue an IPI (via tlb_remove_table_one). This IPI will > block on the gup walker. We need this fallback behaviour on ARM/ARM64. That's my main point: this batch page allocation on the fly for table pages happens in tlb_remove_table(). With your patch for arm64 HAVE_RCU_TABLE_FREE, I can comment out tlb_remove_table() and it compiles just fine because you don't call it from functions like __pte_free_tlb() (as powerpc and sparc do). The __tlb_remove_page() that we currently use doesn't give us any RCU protection here. -- Catalin -- 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>