linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Wei Yang <richard.weiyang@gmail.com>
To: akpm@linux-foundation.org, david@redhat.com,
	lorenzo.stoakes@oracle.com, ziy@nvidia.com,
	baolin.wang@linux.alibaba.com, Liam.Howlett@oracle.com,
	npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com,
	baohua@kernel.org, lance.yang@linux.dev
Cc: linux-mm@kvack.org, Wei Yang <richard.weiyang@gmail.com>,
	wang lian <lianux.mm@gmail.com>
Subject: [Patch v3 3/4] mm/huge_memory: optimize and simplify folio stat update after split
Date: Tue, 21 Oct 2025 21:21:41 +0000	[thread overview]
Message-ID: <20251021212142.25766-4-richard.weiyang@gmail.com> (raw)
In-Reply-To: <20251021212142.25766-1-richard.weiyang@gmail.com>

The loop executed after a successful folio split currently has two
combined responsibilities:

  * updating statistics for the new folios
  * determining the folio for the next split iteration.

This commit refactors the logic to directly calculate and update folio
statistics, eliminating the need for the iteration step.

We can do this because all necessary information is already available:

  * All resulting new folios have the same order, which is @split_order.
  * The exact number of new folios can be calculated directly using
    @old_order and @split_order.
  * The folio for the subsequent split is simply the one containing
    @split_at.

By leveraging this knowledge, we can achieve the stat update more
cleanly and efficiently without the looping logic.

Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
Cc: Zi Yan <ziy@nvidia.com>
Cc: wang lian <lianux.mm@gmail.com>
---
 mm/huge_memory.c | 18 ++++--------------
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index b9a38dba8eb8..093b3ffb180f 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -3598,7 +3598,6 @@ static int __split_unmapped_folio(struct folio *folio, int new_order,
 	const bool is_anon = folio_test_anon(folio);
 	int order = folio_order(folio);
 	int start_order = uniform_split ? new_order : order - 1;
-	struct folio *next;
 	int split_order;
 
 	folio_clear_has_hwpoisoned(folio);
@@ -3610,9 +3609,8 @@ static int __split_unmapped_folio(struct folio *folio, int new_order,
 	for (split_order = start_order;
 	     split_order >= new_order;
 	     split_order--) {
-		struct folio *end_folio = folio_next(folio);
 		int old_order = folio_order(folio);
-		struct folio *new_folio;
+		int nr_new_folios = 1UL << (old_order - split_order);
 
 		/* order-1 anonymous folio is not supported */
 		if (is_anon && split_order == 1)
@@ -3641,19 +3639,11 @@ static int __split_unmapped_folio(struct folio *folio, int new_order,
 		pgalloc_tag_split(folio, old_order, split_order);
 		__split_folio_to_order(folio, old_order, split_order);
 
-		if (is_anon)
+		if (is_anon) {
 			mod_mthp_stat(old_order, MTHP_STAT_NR_ANON, -1);
-		/*
-		 * Iterate through after-split folios and update folio stats.
-		 */
-		for (new_folio = folio; new_folio != end_folio; new_folio = next) {
-			next = folio_next(new_folio);
-			if (new_folio == page_folio(split_at))
-				folio = new_folio;
-			if (is_anon)
-				mod_mthp_stat(folio_order(new_folio),
-					      MTHP_STAT_NR_ANON, 1);
+			mod_mthp_stat(split_order, MTHP_STAT_NR_ANON, nr_new_folios);
 		}
+		folio = page_folio(split_at);
 	}
 
 	return 0;
-- 
2.34.1



  parent reply	other threads:[~2025-10-21 21:22 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-21 21:21 [Patch v3 0/4] mm/huge_memory: cleanup __split_unmapped_folio() Wei Yang
2025-10-21 21:21 ` [Patch v3 1/4] mm/huge_memory: avoid reinvoking folio_test_anon() Wei Yang
2025-10-24 14:08   ` Lorenzo Stoakes
2025-10-21 21:21 ` [Patch v3 2/4] mm/huge_memory: update folio stat after successful split Wei Yang
2025-10-22 20:26   ` David Hildenbrand
2025-10-22 20:31   ` Zi Yan
2025-10-23  1:26   ` wang lian
2025-10-24 14:32   ` Lorenzo Stoakes
2025-10-31  0:46     ` Wei Yang
2025-10-21 21:21 ` Wei Yang [this message]
2025-10-22 20:28   ` [Patch v3 3/4] mm/huge_memory: optimize and simplify folio stat update after split David Hildenbrand
2025-10-22 20:32   ` Zi Yan
2025-10-23  1:29   ` wang lian
2025-10-24 14:35   ` Lorenzo Stoakes
2025-10-21 21:21 ` [Patch v3 4/4] mm/huge_memory: optimize old_order derivation during folio splitting Wei Yang
2025-10-22 20:29   ` David Hildenbrand
2025-10-22 20:33   ` Zi Yan
2025-10-23  1:32   ` wang lian
2025-10-24 14:46   ` Lorenzo Stoakes
2025-10-24 15:29     ` Zi Yan
2025-10-24 15:33       ` Lorenzo Stoakes
2025-10-31  1:50       ` Wei Yang
2025-10-31  1:55         ` Zi Yan
2025-10-31  2:00           ` Wei Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251021212142.25766-4-richard.weiyang@gmail.com \
    --to=richard.weiyang@gmail.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@redhat.com \
    --cc=dev.jain@arm.com \
    --cc=lance.yang@linux.dev \
    --cc=lianux.mm@gmail.com \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=npache@redhat.com \
    --cc=ryan.roberts@arm.com \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).