All of lore.kernel.org
 help / color / mirror / Atom feed
* + mm-huge_memory-use-folio_expected_ref_count-to-calculate-ref_count.patch added to mm-unstable branch
@ 2025-07-14 23:03 Andrew Morton
  0 siblings, 0 replies; only message in thread
From: Andrew Morton @ 2025-07-14 23:03 UTC (permalink / raw)
  To: mm-commits, ryan.roberts, npache, lorenzo.stoakes, liam.howlett,
	k.shutemov, hughd, dev.jain, david, baolin.wang, baohua, balbirs,
	ziy, akpm


The patch titled
     Subject: mm/huge_memory: use folio_expected_ref_count() to calculate ref_count
has been added to the -mm mm-unstable branch.  Its filename is
     mm-huge_memory-use-folio_expected_ref_count-to-calculate-ref_count.patch

This patch will shortly appear at
     https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-huge_memory-use-folio_expected_ref_count-to-calculate-ref_count.patch

This patch will later appear in the mm-unstable branch at
    git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***

The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days

------------------------------------------------------
From: Zi Yan <ziy@nvidia.com>
Subject: mm/huge_memory: use folio_expected_ref_count() to calculate ref_count
Date: Mon, 14 Jul 2025 13:18:23 -0400

Patch series "__folio_split() clean up." v3.

Based on the prior discussion[1], this patch improves
__split_unmapped_folio() by making it reusable for splitting unmapped
folios.  This helps avoid the need for a new boolean unmapped parameter to
guard mapping-related code.

An additional benefit is that __split_unmapped_folio() could be called on
after-split folios by __folio_split().  It can enable new split methods. 
For example, at deferred split time, unmapped subpages can scatter
arbitrarily within a large folio, neither uniform nor non-uniform split
can maximize after-split folio orders for mapped subpages.  The hope is
that by calling __split_unmapped_folio() multiple times, a better split
result can be achieved.


This patch (of 2):

Instead of open coding the ref_count calculation, use
folio_expected_ref_count().

Link: https://lkml.kernel.org/r/20250714171823.3626213-3-ziy@nvidia.com
Signed-off-by: Zi Yan <ziy@nvidia.com>
Suggested-by: David Hildenbrand <david@redhat.com>
Acked-by: Balbir Singh <balbirs@nvidia.com>
Acked-by: David Hildenbrand <david@redhat.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: Barry Song <baohua@kernel.org>
Cc: Dev Jain <dev.jain@arm.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Kirill A. Shutemov <k.shutemov@gmail.com>
Cc: Liam Howlett <liam.howlett@oracle.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Mariano Pache <npache@redhat.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/huge_memory.c |   12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

--- a/mm/huge_memory.c~mm-huge_memory-use-folio_expected_ref_count-to-calculate-ref_count
+++ a/mm/huge_memory.c
@@ -3724,6 +3724,7 @@ static int __folio_split(struct folio *f
 	if (folio_ref_freeze(folio, 1 + extra_pins)) {
 		struct address_space *swap_cache = NULL;
 		struct lruvec *lruvec;
+		int expected_refs;
 
 		if (folio_order(folio) > 1 &&
 		    !list_empty(&folio->_deferred_list)) {
@@ -3794,11 +3795,8 @@ static int __folio_split(struct folio *f
 		     new_folio = next) {
 			next = folio_next(new_folio);
 
-			folio_ref_unfreeze(
-				new_folio,
-				1 + ((mapping || swap_cache) ?
-					     folio_nr_pages(new_folio) :
-					     0));
+			expected_refs = folio_expected_ref_count(new_folio) + 1;
+			folio_ref_unfreeze(new_folio, expected_refs);
 
 			lru_add_split_folio(folio, new_folio, lruvec, list);
 
@@ -3828,8 +3826,8 @@ static int __folio_split(struct folio *f
 		 * Otherwise, a parallel folio_try_get() can grab origin_folio
 		 * and its caller can see stale page cache entries.
 		 */
-		folio_ref_unfreeze(folio, 1 +
-			((mapping || swap_cache) ? folio_nr_pages(folio) : 0));
+		expected_refs = folio_expected_ref_count(folio) + 1;
+		folio_ref_unfreeze(folio, expected_refs);
 
 		unlock_page_lruvec(lruvec);
 
_

Patches currently in -mm which might be from ziy@nvidia.com are

selftests-mm-fix-split_huge_page_test-for-folio_split-tests.patch
mm-huge_memory-move-unrelated-code-out-of-__split_unmapped_folio.patch
mm-huge_memory-use-folio_expected_ref_count-to-calculate-ref_count.patch


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2025-07-14 23:03 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-14 23:03 + mm-huge_memory-use-folio_expected_ref_count-to-calculate-ref_count.patch added to mm-unstable branch Andrew Morton

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.