From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0CB15C07E95 for ; Tue, 20 Jul 2021 20:53:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A0F5760FF3 for ; Tue, 20 Jul 2021 20:53:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A0F5760FF3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 421F26B0011; Tue, 20 Jul 2021 16:53:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D2D16B0036; Tue, 20 Jul 2021 16:53:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 24C416B006C; Tue, 20 Jul 2021 16:53:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0134.hostedemail.com [216.40.44.134]) by kanga.kvack.org (Postfix) with ESMTP id F04F46B0011 for ; Tue, 20 Jul 2021 16:53:56 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 63B641807B529 for ; Tue, 20 Jul 2021 20:53:55 +0000 (UTC) X-FDA: 78384168030.02.5B802E2 Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) by imf29.hostedemail.com (Postfix) with ESMTP id 200199002585 for ; Tue, 20 Jul 2021 20:53:54 +0000 (UTC) Received: by mail-ej1-f54.google.com with SMTP id gb6so36269356ejc.5 for ; Tue, 20 Jul 2021 13:53:54 -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=VFrrCBsxax2vc7LjOi/vF2+yOAND17Gz0+aihbWXbMTinl8vMMiRCswm3HGW6/zHoq 6GCztwxDa7tNyXpYSdDEipduykl0PnV0JVKtgpIEQ+Dpbdm7a4FUOoujdpIDnyjeBWYH iie6zu4MnVbabdoIzOj566kTOJhN4ugxJoz8J5EK0Np3FAz3F6dN35/LeRflGTeKuCGN jVcvsh0pGxAD3gMOzHcek1/QrTqqIhadsqMxuxQ4GQyXmlZyUzsaWDf18n+IizSniKsZ rJrZuOXTj+A/uN+dO0IrwPhFYjt0nt8FYXaLAjs/wQKgmQRVmfsoR+Zsaude0ZUi52Nd 98NQ== X-Gm-Message-State: AOAM531xTqKb6+5l0tLLldKGtyZjsdZK+9igFH8PADKRGhdiqrKdVntp z86ZDEblO7spkL0x0rP/jsqsSOVrRlJUMMOPdPw= X-Google-Smtp-Source: ABdhPJwUAntyq17ENwtwuvmBlgGc6On+crRf2x/UG5Ey0hWO7A9tRypRUaEosm0MRG3hgYJ+pgeYJHAQyPd6Thw1qro= 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" Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=OftM9WCE; spf=pass (imf29.hostedemail.com: domain of shy828301@gmail.com designates 209.85.218.54 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam05 X-Stat-Signature: hq5p6ty1enfofpnexc94mdqsjf9rayru X-Rspamd-Queue-Id: 200199002585 X-HE-Tag: 1626814434-14404 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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) > >