From patchwork Thu Jul 1 01:51:07 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12353207 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=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_RED autolearn=unavailable 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 1E15CC11F69 for ; Thu, 1 Jul 2021 01:51:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B49C561241 for ; Thu, 1 Jul 2021 01:51:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B49C561241 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3CF158D021E; Wed, 30 Jun 2021 21:51:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 37F1E8D0202; Wed, 30 Jun 2021 21:51:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 26DE88D021E; Wed, 30 Jun 2021 21:51:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0023.hostedemail.com [216.40.44.23]) by kanga.kvack.org (Postfix) with ESMTP id F086F8D0202 for ; Wed, 30 Jun 2021 21:51:08 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id A41B5827DC63 for ; Thu, 1 Jul 2021 01:51:08 +0000 (UTC) X-FDA: 78312341016.10.0DEC2E7 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf17.hostedemail.com (Postfix) with ESMTP id 63D73F000129 for ; Thu, 1 Jul 2021 01:51:08 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 6D61161469; Thu, 1 Jul 2021 01:51:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1625104267; bh=wRLv2R4QkVRlU9cMNpyvXuwwWaXnK1gjWRMys2tx4m4=; h=Date:From:To:Subject:In-Reply-To:From; b=YHJTdK7r+SzJpFm3Nh46cN7R4Na9264fbXr8eE3g+D80zpp7+4Gffu3e5tDDA+E4G 9dePyASu7qcMkf/QshB6gNhpZ7lv0cbQwUpUWgq9/h5EqIrRjkm3E5kK5ootxYoS0s AU0KQinEnniGljgw5Y4OuRZfOe3vHCLiLHyFQ0wY= Date: Wed, 30 Jun 2021 18:51:07 -0700 From: Andrew Morton To: akpm@linux-foundation.org, hughd@google.com, kirill.shutemov@linux.intel.com, linux-mm@kvack.org, mhocko@suse.com, mm-commits@vger.kernel.org, nao.horiguchi@gmail.com, shy828301@gmail.com, torvalds@linux-foundation.org, ziy@nvidia.com Subject: [patch 074/192] mm: mempolicy: don't have to split pmd for huge zero page Message-ID: <20210701015107.mLNtftQiK%akpm@linux-foundation.org> In-Reply-To: <20210630184624.9ca1937310b0dd5ce66b30e7@linux-foundation.org> User-Agent: s-nail v14.8.16 Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=YHJTdK7r; spf=pass (imf17.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Stat-Signature: 4hso7xqozjbmoenste57iz9e9buz4zao X-Rspamd-Queue-Id: 63D73F000129 X-Rspamd-Server: rspam06 X-HE-Tag: 1625104268-952101 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: From: Yang Shi Subject: mm: mempolicy: don't have to split pmd for huge zero page When trying to migrate pages to obey mempolicy, the huge zero page is split by inserting base zero pfn to all PTEs, then the page table walk fallback to PTE level and just skips zero page. Skipping zero page for mempolicy has been the behavior of kernel since v2.6.16 due to commit f4598c8b3678 ("[PATCH] migration: make sure there is no attempt to migrate reserved pages."). So it seems pointless to split huge zero page, it could be just skipped like base zero page. Set ACTION_CONTINUE to prevent the walk_page_range() split the pmd for this case. Link: https://lkml.kernel.org/r/20210609172146.3594-1-shy828301@gmail.com Link: https://lkml.kernel.org/r/20210604203513.240709-1-shy828301@gmail.com Signed-off-by: Yang Shi Reviewed-by: Zi Yan Acked-by: Michal Hocko Cc: Naoya Horiguchi Cc: Kirill A. Shutemov Cc: Hugh Dickins Signed-off-by: Andrew Morton --- mm/mempolicy.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) --- a/mm/mempolicy.c~mm-mempolicy-dont-have-to-split-pmd-for-huge-zero-page +++ a/mm/mempolicy.c @@ -437,7 +437,8 @@ static inline bool queue_pages_required( /* * queue_pages_pmd() has four possible return values: - * 0 - pages are placed on the right node or queued successfully. + * 0 - pages are placed on the right node or queued successfully, or + * special page is met, i.e. huge zero page. * 1 - there is unmovable page, and MPOL_MF_MOVE* & MPOL_MF_STRICT were * specified. * 2 - THP was split. @@ -461,8 +462,7 @@ static int queue_pages_pmd(pmd_t *pmd, s page = pmd_page(*pmd); if (is_huge_zero_page(page)) { spin_unlock(ptl); - __split_huge_pmd(walk->vma, pmd, addr, false, NULL); - ret = 2; + walk->action = ACTION_CONTINUE; goto out; } if (!queue_pages_required(page, qp)) @@ -489,7 +489,8 @@ out: * and move them to the pagelist if they do. * * queue_pages_pte_range() has three possible return values: - * 0 - pages are placed on the right node or queued successfully. + * 0 - pages are placed on the right node or queued successfully, or + * special page is met, i.e. zero page. * 1 - there is unmovable page, and MPOL_MF_MOVE* & MPOL_MF_STRICT were * specified. * -EIO - only MPOL_MF_STRICT was specified and an existing page was already