Message ID | 20230728161356.1784568-3-fengwei.yin@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:918b:0:b0:3e4:2afc:c1 with SMTP id s11csp571895vqg; Fri, 28 Jul 2023 10:03:53 -0700 (PDT) X-Google-Smtp-Source: APBJJlFUjEq3aWRUMbjkVr7HgKq2Zj6ffxml4eiRHEQjuZiN3rOviFaNP4Jpz5EktCcVnfnzsJuS X-Received: by 2002:a17:90a:3e84:b0:267:f7eb:f12e with SMTP id k4-20020a17090a3e8400b00267f7ebf12emr1986763pjc.39.1690563833433; Fri, 28 Jul 2023 10:03:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690563833; cv=none; d=google.com; s=arc-20160816; b=m408CMexP/zVwODCClbSyu1z8VQuksgy5dlFdKd9nxduGsgFDOyjvI4iYgjKeFmRWE tSoPqTqLjB8T6wpeQA55+QiQGNSCVvIsmEiwWSyvCUn5XV2N67LT8uVeKrEGL0cqIzr3 2Dc386B6pCML8i86OJzs8tYuA4aqnY+uR8kyLWko2Vr7YftWy35VwaWWkj2hcPbOHepd OSjsNcSVNlq/QACVs2Yub0OHD/t8jV0e3ddj4ED3Q5Qv5n6OemeGzxJ1EOEs/f+OnDZU yWBRyQ7+PSaj9Xc93wQ67Ay1vN3jqbdXUVDFgPLzUIKAY+wyjwoACmMSedRVfPLThHBn kRKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=xUoEr5I95lUh9hjBzY7s8yEoirfYNyR/ZKYQRhAtaJQ=; fh=LgrQy7mqd4cTuAw7dlguzqzf4K4OZS27s5hhhI8E0EA=; b=oTl6S0wpBBhS5YIwo5PFCj689MhG1KIRR18QSzLqL0edWq6dKKtDMS963UQsrW2GlZ eng2x2UUYrMuc08WC/jK+J56p0fxZVgBOmSz+EOIVO3QLQZYo01VdibdMr4bai5EVcZy e4p/4f8uDt6qqNyHik5vtFLkxAliu+8UFJGkOKqa4Qf53RXdXIyO1eYUjjlCcXBwNJ7z WdtcoKgDWsiOkZ2yJ+al7PD3CIVfosIdRFMEJ+MlZtBP/0BdS2Cv/S7qJysLUujDsawZ 5nV+1PE9oYlimLluDPP8R3YhBKrqRvporLxUOT7sp9S2qtMyHOd3ju9egG3UF7+xCv2A uwpA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Bx93Gn62; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u22-20020a17090ae01600b00262ecc1963fsi4868612pjy.33.2023.07.28.10.03.39; Fri, 28 Jul 2023 10:03:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Bx93Gn62; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229838AbjG1QQG (ORCPT <rfc822;hanasaki@gmail.com> + 99 others); Fri, 28 Jul 2023 12:16:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58632 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231202AbjG1QQE (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 28 Jul 2023 12:16:04 -0400 Received: from mgamail.intel.com (unknown [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E85274495; Fri, 28 Jul 2023 09:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1690560954; x=1722096954; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=BrOxNMR67qVjTh31EvN6swY79AWjbm/yuEvrka6JwLk=; b=Bx93Gn62Ao7K22b9ZrdhENFQp506SfkfJ1L4L+lpju0JXDcgR/5/M8ts R2705USmIZuvZiFKTfBk4foJCy3auz+Hpsp9kWwYPhisU1IRLzkq2mukB /BARqLL5DnuRTJ9GO7OQoHXAeBdHNyEYYgFn2INksHxEWlFRUKDHVA2/P WiDbgQs9ZrE17x6cUM/sUgPj5+e+HbPMu6iRqJQQ0efR2XvBQONdE6DH6 GgZRwbKZpPnI5BWJLC6eEY3R1c1p+XFAB/FZjtWd7teyPdTrw4lWXFBFT 9G2AD7My68B4w+hWoGTFDdioXPoPynN9Mhjiv7NkSIlEgW1mc+88OV7vT Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10784"; a="399566016" X-IronPort-AV: E=Sophos;i="6.01,238,1684825200"; d="scan'208";a="399566016" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jul 2023 09:15:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10784"; a="974142248" X-IronPort-AV: E=Sophos;i="6.01,238,1684825200"; d="scan'208";a="974142248" Received: from fyin-dev.sh.intel.com ([10.239.159.32]) by fmsmga006.fm.intel.com with ESMTP; 28 Jul 2023 09:15:51 -0700 From: Yin Fengwei <fengwei.yin@intel.com> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, akpm@linux-foundation.org, willy@infradead.org, vishal.moola@gmail.com, wangkefeng.wang@huawei.com, minchan@kernel.org, yuzhao@google.com, david@redhat.com, ryan.roberts@arm.com, shy828301@gmail.com Cc: fengwei.yin@intel.com Subject: [PATCH 2/2] madvise: don't use mapcount() against large folio for sharing check Date: Sat, 29 Jul 2023 00:13:56 +0800 Message-Id: <20230728161356.1784568-3-fengwei.yin@intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230728161356.1784568-1-fengwei.yin@intel.com> References: <20230728161356.1784568-1-fengwei.yin@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1772684662198816631 X-GMAIL-MSGID: 1772684662198816631 |
Series |
don't use mapcount() to check large folio sharing
|
|
Commit Message
Yin Fengwei
July 28, 2023, 4:13 p.m. UTC
The commits 98b211d6415f ("madvise: convert madvise_free_pte_range() to use a folio") fc986a38b670 ("mm: huge_memory: convert madvise_free_huge_pmd to use a folio") replaced the page_mapcount() with folio_mapcount() to check whether the folio is shared by other mapping. But it's not correct for large folio. folio_mapcount() returns the total mapcount of large folio which is not suitable to detect whether the folio is shared. Use folio_estimated_sharers() which returns a estimated number of shares. That means it's not 100% correct. But it should be OK for madvise case here. Fixes: 98b211d6415f ("madvise: convert madvise_free_pte_range() to use a folio") Fixes: fc986a38b670 ("mm: huge_memory: convert madvise_free_huge_pmd to use a folio") Signed-off-by: Yin Fengwei <fengwei.yin@intel.com> Reviewed-by: Yu Zhao <yuzhao@google.com> --- mm/huge_memory.c | 2 +- mm/madvise.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
Comments
On Sat, 29 Jul 2023 00:13:56 +0800 Yin Fengwei <fengwei.yin@intel.com> wrote: > Fixes: 98b211d6415f ("madvise: convert madvise_free_pte_range() to use a folio") > Fixes: fc986a38b670 ("mm: huge_memory: convert madvise_free_huge_pmd to use a folio") Having two Fixes: for one patch presumably makes backporting more complicated and adds risk of making mistakes. So I have split this into a three-patch series and I've fixed up the patch naming: Subject: madvise:madvise_cold_or_pageout_pte_range(): don't use mapcount() against large folio for sharing check Subject: madvise:madvise_free_huge_pmd(): don't use mapcount() against large folio for sharing check Subject: madvise:madvise_free_pte_range(): don't use mapcount() against large folio for sharing check I haven't added cc:stable at this time - that awaits the description of user-visible effects.
Hi Andrew, On 7/29/2023 1:41 AM, Andrew Morton wrote: > On Sat, 29 Jul 2023 00:13:56 +0800 Yin Fengwei <fengwei.yin@intel.com> wrote: > >> Fixes: 98b211d6415f ("madvise: convert madvise_free_pte_range() to use a folio") >> Fixes: fc986a38b670 ("mm: huge_memory: convert madvise_free_huge_pmd to use a folio") > > Having two Fixes: for one patch presumably makes backporting more > complicated and adds risk of making mistakes. > > So I have split this into a three-patch series and I've fixed up the patch naming: > > Subject: madvise:madvise_cold_or_pageout_pte_range(): don't use mapcount() against large folio for sharing check > Subject: madvise:madvise_free_huge_pmd(): don't use mapcount() against large folio for sharing check > Subject: madvise:madvise_free_pte_range(): don't use mapcount() against large folio for sharing check Thanks a lot for your kind help. Will be careful for the future patches. > > I haven't added cc:stable at this time - that awaits the description of > user-visible effects. The impact of the patch: Without the patch, when user calls madvise() with MADV_COLD, MADV_PAGEOUT and MADV_FREE, it's likely THP pages will be skipped. With the patch, It's likely the THP pages will be split to pages which will be made code, reclaimed and freed. Regards Yin, Fengwei
diff --git a/mm/huge_memory.c b/mm/huge_memory.c index eb3678360b97..68c890875257 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1613,7 +1613,7 @@ bool madvise_free_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, * If other processes are mapping this folio, we couldn't discard * the folio unless they all do MADV_FREE so let's skip the folio. */ - if (folio_mapcount(folio) != 1) + if (folio_estimated_sharers(folio) != 1) goto out; if (!folio_trylock(folio)) diff --git a/mm/madvise.c b/mm/madvise.c index 148b46beb039..55bdf641abfa 100644 --- a/mm/madvise.c +++ b/mm/madvise.c @@ -678,7 +678,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr, if (folio_test_large(folio)) { int err; - if (folio_mapcount(folio) != 1) + if (folio_estimated_sharers(folio) != 1) break; if (!folio_trylock(folio)) break;