From nobody Sat Feb 7 08:45:13 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 668E3C00528 for ; Tue, 8 Aug 2023 02:11:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230055AbjHHCLA (ORCPT ); Mon, 7 Aug 2023 22:11:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229566AbjHHCK6 (ORCPT ); Mon, 7 Aug 2023 22:10:58 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C25A81711; Mon, 7 Aug 2023 19:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1691460653; x=1722996653; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=I0sX9zQ55/pnapaBgwBXw+8hFPy7SpHzYq+j/u0jVVw=; b=joHMlYxPWu5ShZUS3ILS82ZCwlpnmi4lVi9vegrtgdysZxfHyxdrnQ/D BgazzmrzTSeruioIdqjDbJ2m+SurGkS8iPoZpMBmyTePexgZhwskY8B11 Bxlp/KKRbOgkunLaSF338P+TrHTdOD7+AZZ24CkASRQF7dx/gxMbMbQaW lh/TR72cOLj2VtPBe6gKCDuhvLP+CUuDM9qfZQewLtP9+Dqu6XPwdZEFm waVmeP0UbDZ7ekGPUU4LU4CqPQuMvAhd6afKPDBwDH/gUgCPHoiu4Cq1i IzZCjUIH3facI05fgHwNFaPgUMSbD7KQ16NKzkoVtir5m45n8/rgufyY/ w==; X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="373453505" X-IronPort-AV: E=Sophos;i="6.01,263,1684825200"; d="scan'208";a="373453505" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Aug 2023 19:10:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="977689341" X-IronPort-AV: E=Sophos;i="6.01,263,1684825200"; d="scan'208";a="977689341" Received: from fyin-dev.sh.intel.com ([10.239.159.32]) by fmsmga006.fm.intel.com with ESMTP; 07 Aug 2023 19:10:49 -0700 From: Yin Fengwei 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 v2 1/3] madvise:madvise_cold_or_pageout_pte_range(): don't use mapcount() against large folio for sharing check Date: Tue, 8 Aug 2023 10:09:15 +0800 Message-Id: <20230808020917.2230692-2-fengwei.yin@intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230808020917.2230692-1-fengwei.yin@intel.com> References: <20230808020917.2230692-1-fengwei.yin@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Commit 07e8c82b5eff ("madvise: convert madvise_cold_or_pageout_pte_range() to use folios") replaced the page_mapcount() with folio_mapcount() to check whether the folio is shared by other mapping. 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. It should be OK for madvise case here. User-visible effects is that the THP is skipped when user call madvise. But the correct behavior is THP should be split and processed then. NOTE: this change is a temporary fix to reduce the user-visible effects before the long term fix from David is ready. Fixes: 07e8c82b5eff ("madvise: convert madvise_cold_or_pageout_pte_range() = to use folios") Cc: stable@vger.kernel.org Signed-off-by: Yin Fengwei Reviewed-by: Yu Zhao Reviewed-by: Ryan Roberts --- mm/madvise.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/madvise.c b/mm/madvise.c index 1d7933933e31..49af35e2d99a 100644 --- a/mm/madvise.c +++ b/mm/madvise.c @@ -383,7 +383,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd, folio =3D pfn_folio(pmd_pfn(orig_pmd)); =20 /* Do not interfere with other mappings of this folio */ - if (folio_mapcount(folio) !=3D 1) + if (folio_estimated_sharers(folio) !=3D 1) goto huge_unlock; =20 if (pageout_anon_only_filter && !folio_test_anon(folio)) @@ -459,7 +459,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd, if (folio_test_large(folio)) { int err; =20 - if (folio_mapcount(folio) !=3D 1) + if (folio_estimated_sharers(folio) !=3D 1) break; if (pageout_anon_only_filter && !folio_test_anon(folio)) break; --=20 2.39.2 From nobody Sat Feb 7 08:45:13 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C9281C00528 for ; Tue, 8 Aug 2023 02:11:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229623AbjHHCLL (ORCPT ); Mon, 7 Aug 2023 22:11:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43290 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229566AbjHHCLI (ORCPT ); Mon, 7 Aug 2023 22:11:08 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E5CD170B; Mon, 7 Aug 2023 19:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1691460668; x=1722996668; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=F3oORw0alZIlqdHjL/85Fxei/Bpe8d1CgQMNfWf9J+M=; b=mIQNCeW2k5AHYKQUqOV4Wy4/T4s1ba03EWASwQQQIXl8J/DAcH0v76tD ZhVWN40u77qMXYG6cJMpZRf1TMz7+SsY+QcXTNI8632jjM7xMz7SHpb39 vXgQ9Ba3jKt0/xEnHoyFBxIwrA7XNONSVZA2uQnBXFUG3k+C9+HG1GG7J Jwwqx6tTAZfZ/xw1mtyKLScDN/3mS7VGXZL7O0lhd8I9PImB/H0xqG7A7 rcsvqB32Z1uSkEYW8mkGvRn7xJikVHRw3hk4v6JLeMh4W1b3A4LZ1p/r2 bpjfIsA/QO0hufw23pU/UwuRqQadG5bOsFOLSqdFkhPRYIrTkW7tOi+gF Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="374371058" X-IronPort-AV: E=Sophos;i="6.01,263,1684825200"; d="scan'208";a="374371058" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Aug 2023 19:11:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="681051006" X-IronPort-AV: E=Sophos;i="6.01,263,1684825200"; d="scan'208";a="681051006" Received: from fyin-dev.sh.intel.com ([10.239.159.32]) by orsmga003.jf.intel.com with ESMTP; 07 Aug 2023 19:11:03 -0700 From: Yin Fengwei 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 v2 2/3] madvise:madvise_free_huge_pmd(): don't use mapcount() against large folio for sharing check Date: Tue, 8 Aug 2023 10:09:16 +0800 Message-Id: <20230808020917.2230692-3-fengwei.yin@intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230808020917.2230692-1-fengwei.yin@intel.com> References: <20230808020917.2230692-1-fengwei.yin@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Commit 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. It's not correct for large folios. 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. It should be OK for madvise case here. User-visible effects is that the THP is skipped when user call madvise. But the correct behavior is THP should be split and processed then. NOTE: this change is a temporary fix to reduce the user-visible effects before the long term fix from David is ready. Fixes: fc986a38b670 ("mm: huge_memory: convert madvise_free_huge_pmd to use= a folio") Cc: stable@vger.kernel.org Signed-off-by: Yin Fengwei Reviewed-by: Yu Zhao Reviewed-by: Ryan Roberts --- mm/huge_memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 154c210892a1..0b709d2c46c6 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1612,7 +1612,7 @@ bool madvise_free_huge_pmd(struct mmu_gather *tlb, st= ruct 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) !=3D 1) + if (folio_estimated_sharers(folio) !=3D 1) goto out; =20 if (!folio_trylock(folio)) --=20 2.39.2 From nobody Sat Feb 7 08:45:13 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9DA68C41513 for ; Tue, 8 Aug 2023 02:11:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230263AbjHHCLb (ORCPT ); Mon, 7 Aug 2023 22:11:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229566AbjHHCL3 (ORCPT ); Mon, 7 Aug 2023 22:11:29 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C6ED19B6; Mon, 7 Aug 2023 19:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1691460682; x=1722996682; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=d3VIX2xY+fu1wWsahOfoN14pobtO1cM2MgEWqpBvgLY=; b=EuJd4qa0AAArhVMsFAlVuljUHzrNuN+NCuFOvd/FratfgL2JETvU6eCh qg6KhSCb58AqZmPXhmlnGTLUklrJP7iYSWSXQYEQRj7TcTSSk+e0wJc+m JURZuL/L5ni+vhYi93jQ0OaAWfp8hWPV15Xe0MPextHEwx2/gBdsKQHPx 12/mcxBQm0bm7Olx+egeufVxqoqMDaxF/ysXGR2cqJc/UB5n5PAPL8Hvp iQzc2W1QdyXnuBwG/qtj/XSzk3PlTQcOZVp0R3aZ0IrVRgu1tzPhbFvzG dsZRTrN9URLfshzRnuKIzObcL+fm3PdBJpkYAg1HUJIQWN7+NgtF1ONx1 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="373453596" X-IronPort-AV: E=Sophos;i="6.01,263,1684825200"; d="scan'208";a="373453596" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Aug 2023 19:11:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="977689411" X-IronPort-AV: E=Sophos;i="6.01,263,1684825200"; d="scan'208";a="977689411" Received: from fyin-dev.sh.intel.com ([10.239.159.32]) by fmsmga006.fm.intel.com with ESMTP; 07 Aug 2023 19:11:18 -0700 From: Yin Fengwei 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 v2 3/3] madvise:madvise_free_pte_range(): don't use mapcount() against large folio for sharing check Date: Tue, 8 Aug 2023 10:09:17 +0800 Message-Id: <20230808020917.2230692-4-fengwei.yin@intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230808020917.2230692-1-fengwei.yin@intel.com> References: <20230808020917.2230692-1-fengwei.yin@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Commit 98b211d6415f ("madvise: convert madvise_free_pte_range() to use a folio") replaced the page_mapcount() with folio_mapcount() to check whether the folio is shared by other mapping. It's not correct for large folios. 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. It should be OK for madvise case here. User-visible effects is that the THP is skipped when user call madvise. But the correct behavior is THP should be split and processed then. NOTE: this change is a temporary fix to reduce the user-visible effects before the long term fix from David is ready. Fixes: 98b211d6415f ("madvise: convert madvise_free_pte_range() to use a fo= lio") Cc: stable@vger.kernel.org Signed-off-by: Yin Fengwei Reviewed-by: Yu Zhao Reviewed-by: Ryan Roberts --- mm/madvise.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/madvise.c b/mm/madvise.c index 49af35e2d99a..4dded5d27e7e 100644 --- a/mm/madvise.c +++ b/mm/madvise.c @@ -683,7 +683,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned = long addr, if (folio_test_large(folio)) { int err; =20 - if (folio_mapcount(folio) !=3D 1) + if (folio_estimated_sharers(folio) !=3D 1) break; if (!folio_trylock(folio)) break; --=20 2.39.2