Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp4896920pxv; Tue, 20 Jul 2021 14:01:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyJaUdGZ1s+dzo+5GqI4k4FY8rZxCwuxHSMECd74/vXA3x6Oybc3RVjNzTM+1W19DtOebyO X-Received: by 2002:a02:2a88:: with SMTP id w130mr27796025jaw.60.1626814879364; Tue, 20 Jul 2021 14:01:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626814879; cv=none; d=google.com; s=arc-20160816; b=yJr5MjHKcyv7ZLQ8CK2RxLMRjW6E5/gAw7ZUggiJTs/mN1rqS0Wx2GS60KkeMtjj8u ZU6ip6YHL+0r5GkeO1srxY92KdHQ/9ybfsfOo9RWQr9pzGEbjwikDz5QKE2+XJaf+Tpa 1DU1unmmtgq1EGeXAQiNln1x8bHmGZhY9nxL2HSf9jU8M0w9S0NjPlLq/nMmqdz400n7 ytsa25uQJ8PXrwyCav4D1MaOQ6jRGlSEwNuGcllE9vMOET/tnRRAzBF68rMvR+Zg1eSY HOsmax+ZBdGfShSIzlg/zekdWFPkGlVMKXFFTS3083D6t1dd6MsMPQuuDUMq06g6wrBZ FB8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=44qk/SPvu//rgjLJF5jwtYI5ft2vVL7G4C4DfylIoXY=; b=c0Z6emBDCCF0BZmFu2x2bAF8jv+uX71fprNA2/RHatWAp5hwHlUERCKcImbsYXcOQN SpcrFZviqSMN7+xVEld4svlaQcUdcYREccGqDwwoTlgpXZvKe6cnA7anOeOP9/PQqkaZ pQ7vhy7BwXY5dZpc7IaZqg2U5GtA4smjn2K57ZW6/vGwLoOp+VgZd4hW1xPNw2k2es0s 9na7FHWRLsGckn0pXvedXSHVSKrsPHWpqFd1wJmA78CKEl17qxgU227uW8C/nkuSRSFd oTR9XmaFmmvidAEoPAGIIGtwrWYy9n3ZHIpiJ++BdGrvcmjJFsEOqNRyYVQbR8ZgrX9r V9Zg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OftM9WCE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h13si24569716iop.97.2021.07.20.14.01.06; Tue, 20 Jul 2021 14:01:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OftM9WCE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230134AbhGTUS6 (ORCPT + 99 others); Tue, 20 Jul 2021 16:18:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44944 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234709AbhGTUNc (ORCPT ); Tue, 20 Jul 2021 16:13:32 -0400 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 81AB2C061574; Tue, 20 Jul 2021 13:53:55 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id qa36so14911840ejc.10; Tue, 20 Jul 2021 13:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=44qk/SPvu//rgjLJF5jwtYI5ft2vVL7G4C4DfylIoXY=; b=OftM9WCENnpMqTUJsIA3MKKjn708iT/Lw3yrY6lH1pEDZ27vJs7PaELvwkvhNb8fmq TjIN5vWnEzofvLkBgJEnMz+x9HVXlenHZlFjtpMGCMvkk8h6cYk1gulnF1aNzwJNTTLe +Wb57w1ZES/sxVHMNDmVbbYawPgdjbEyJSny4a3qM5jkJ1EmXKm6dzYC5fG0O6gGW/eW mrrsdNiL6JC6ad6SN09iCU9B6OXaIIEbe0vZElpqM2NfG0owmt+qu0lOZ5DNKdzBAK/Y s/1nloGCdGw9CWDd/JVvMBPp8MG2Kr5EyKI1mhcQ/Wl9BJ2PFTz2qkr3d2mCOfTwLTTN zfTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=44qk/SPvu//rgjLJF5jwtYI5ft2vVL7G4C4DfylIoXY=; b=PTJntb9Yj0H3GG2xCnYLnemGMTENnmwjqOPhpR9etYqMt+pQZhsEHdOV/VXkqMJtmu uSf/3KPFEZQyXRItMKts2E9vcUJNznMpI6lWWbAzLSrNe7X4Gcppu+452RPv2JiNpr2n R1+xZR2DTOr/g/BlscHCWwe3qZ7+GHCIwXr7inyq5N5HuBYIpokTyE9ig6fIP9ik+CTo oJFoU6hzyPk9LEhV5PavoWBqxX36ZxDvkjVXDfGnYDDMlBJ0vKbmKE+BbynpYDiUuIYB r8o+2dnGPvmUBUfr5wA2fTMP6BOdfyGKSjuufjJGeqCN4OW3fQOQtOo7hbcqfMYyGr80 2Y5g== X-Gm-Message-State: AOAM531wxD05YYXi+dZyLVlk0aNLM8BSybvVaU5oL16IfGVUGkY3nfM2 dWxgjC6r5zFj82aWJlSjXk+sqCB2vr8Pvp4dGsc= X-Received: by 2002:a17:907:4cf:: with SMTP id vz15mr34336344ejb.161.1626814434101; Tue, 20 Jul 2021 13:53:54 -0700 (PDT) MIME-Version: 1.0 References: <20210720065529.716031-1-ying.huang@intel.com> In-Reply-To: From: Yang Shi Date: Tue, 20 Jul 2021 13:53:39 -0700 Message-ID: Subject: Re: [PATCH] mm,do_huge_pmd_numa_page: remove unnecessary TLB flushing code To: Christian Borntraeger Cc: Huang Ying , Andrew Morton , Linux MM , Linux Kernel Mailing List , Dan Carpenter , Mel Gorman , Gerald Schaefer , Heiko Carstens , Hugh Dickins , Andrea Arcangeli , "Kirill A . Shutemov" , Michal Hocko , Vasily Gorbik , Zi Yan , Paolo Bonzini , kvm list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 20, 2021 at 7:25 AM Christian Borntraeger wrote: > > > > On 20.07.21 08:55, Huang Ying wrote: > > Before the commit c5b5a3dd2c1f ("mm: thp: refactor NUMA fault > > handling"), the TLB flushing is done in do_huge_pmd_numa_page() itself > > via flush_tlb_range(). > > > > But after commit c5b5a3dd2c1f ("mm: thp: refactor NUMA fault > > handling"), the TLB flushing is done in migrate_pages() as in the > > following code path anyway. > > > > do_huge_pmd_numa_page > > migrate_misplaced_page > > migrate_pages > > > > So now, the TLB flushing code in do_huge_pmd_numa_page() becomes > > unnecessary. So the code is deleted in this patch to simplify the > > code. This is only code cleanup, there's no visible performance > > difference. > > > > Signed-off-by: "Huang, Ying" > > Cc: Yang Shi > > Cc: Dan Carpenter > > Cc: Mel Gorman > > Cc: Christian Borntraeger > > Cc: Gerald Schaefer > > Cc: Heiko Carstens > > Cc: Hugh Dickins > > Cc: Andrea Arcangeli > > Cc: Kirill A. Shutemov > > Cc: Michal Hocko > > Cc: Vasily Gorbik > > Cc: Zi Yan > > --- > > mm/huge_memory.c | 26 -------------------------- > > 1 file changed, 26 deletions(-) > > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > index afff3ac87067..9f21e44c9030 100644 > > --- a/mm/huge_memory.c > > +++ b/mm/huge_memory.c > > @@ -1440,32 +1440,6 @@ vm_fault_t do_huge_pmd_numa_page(struct vm_fault *vmf) > > goto out; > > } > > > > - /* > > - * Since we took the NUMA fault, we must have observed the !accessible > > - * bit. Make sure all other CPUs agree with that, to avoid them > > - * modifying the page we're about to migrate. > > - * > > - * Must be done under PTL such that we'll observe the relevant > > - * inc_tlb_flush_pending(). > > - * > > - * We are not sure a pending tlb flush here is for a huge page > > - * mapping or not. Hence use the tlb range variant > > - */ > > - if (mm_tlb_flush_pending(vma->vm_mm)) { > > - flush_tlb_range(vma, haddr, haddr + HPAGE_PMD_SIZE); > > - /* > > - * change_huge_pmd() released the pmd lock before > > - * invalidating the secondary MMUs sharing the primary > > - * MMU pagetables (with ->invalidate_range()). The > > - * mmu_notifier_invalidate_range_end() (which > > - * internally calls ->invalidate_range()) in > > - * change_pmd_range() will run after us, so we can't > > - * rely on it here and we need an explicit invalidate. > > - */ > > - mmu_notifier_invalidate_range(vma->vm_mm, haddr, > > - haddr + HPAGE_PMD_SIZE); > > - } > > CC Paolo/KVM list so we also remove the mmu notifier here. Do we need those > now in migrate_pages? I am not an expert in that code, but I cant find > an equivalent mmu_notifier in migrate_misplaced_pages. > I might be totally wrong, just something that I noticed. Do you mean the missed mmu notifier invalidate for the THP migration case? Yes, I noticed that too. But I'm not sure whether it is intended or just missed. Zi Yan is the author for THP migration code, he may have some clue. > > > pmd = pmd_modify(oldpmd, vma->vm_page_prot); > > page = vm_normal_page_pmd(vma, haddr, pmd); > > if (!page) > >