Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753934AbcK1Rcu (ORCPT ); Mon, 28 Nov 2016 12:32:50 -0500 Received: from mga01.intel.com ([192.55.52.88]:40643 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751591AbcK1Rcl (ORCPT ); Mon, 28 Nov 2016 12:32:41 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,564,1473145200"; d="scan'208";a="906384289" Subject: Re: [PATCH 2/2] mremap: use mmu gather logic for tlb flush in mremap To: Aaron Lu , Linus Torvalds References: <026b73f6-ca1d-e7bb-766c-4aaeb7071ce6@intel.com> <20161128083715.GA21738@aaronlu.sh.intel.com> <20161128084012.GC21738@aaronlu.sh.intel.com> Cc: Linux Memory Management List , Andrew Morton , "Kirill A. Shutemov" , Huang Ying , linux-kernel@vger.kernel.org From: Dave Hansen Message-ID: <31b1393c-22d2-8a49-842c-9678a1921441@intel.com> Date: Mon, 28 Nov 2016 09:32:35 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161128084012.GC21738@aaronlu.sh.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1548 Lines: 33 On 11/28/2016 12:40 AM, Aaron Lu wrote: > As suggested by Linus, the same mmu gather logic could be used for tlb > flush in mremap and this patch just did that. > > Note that since there is no page added to "struct mmu_gather" for free > during mremap, when tlb needs to be flushed, we can use tlb_flush_mmu or > tlb_flush_mmu_tlbonly. Using tlb_flush_mmu could also avoid exporting > tlb_flush_mmu_tlbonly. But tlb_flush_mmu_tlbonly *looks* more clear and > straightforward so I end up using it. OK, so the code before this patch was passing around a pointer to 'need_flush', and we basically just pass around an mmu_gather instead. It doesn't really simplify the code _too_ much, although it does make it less confusing than when we saw 'need_flush' mixed with 'force_flush' in the code. tlb_flush_mmu_tlbonly() has exactly one other use: zap_pte_range() for flushing the TLB before pte_unmap_unlock(): if (force_flush) tlb_flush_mmu_tlbonly(tlb); pte_unmap_unlock(start_pte, ptl); But, both call-sites are still keeping 'force_flush' to store the information about whether we ever saw a dirty pte. If we moved _that_ logic into the x86 mmu_gather code, we could get rid of all the 'force_flush' tracking in both call sites. It also makes us a bit more future-proof against these page_mkclean() races if we ever grow a third site for clearing ptes. Instead of exporting and calling tlb_flush_mmu_tlbonly(), we'd need something like tlb_flush_mmu_before_ptl_release() (but with a better name, of course :).