linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] mm/huge_memory: use end_folio to terminate anonymous folio remapping
@ 2025-11-27  2:24 Wei Yang
  2025-11-27  6:30 ` Lorenzo Stoakes
  2025-11-27  7:22 ` David Hildenbrand (Red Hat)
  0 siblings, 2 replies; 4+ messages in thread
From: Wei Yang @ 2025-11-27  2:24 UTC (permalink / raw)
  To: akpm, david, lorenzo.stoakes, ziy, baolin.wang, Liam.Howlett,
	npache, ryan.roberts, dev.jain, baohua, lance.yang
  Cc: linux-mm, Wei Yang

After splitting a large folio, it is necessary to remap the resulting
anonymous folios.

The current implementation determines the end of the remapping process
by counting the number of pages that have been processed.

Since the final folio in the sequence, end_folio, is already known and
tracked, this commit refactors the remapping loop to leverage end_folio
as the termination marker.

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

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 553bfa961fce..afc7b2f91e99 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -3414,20 +3414,14 @@ bool unmap_huge_pmd_locked(struct vm_area_struct *vma, unsigned long addr,
 	return __discard_anon_folio_pmd_locked(vma, addr, pmdp, folio);
 }
 
-static void remap_page(struct folio *folio, unsigned long nr, int flags)
+static void remap_page(struct folio *folio, struct folio *end_folio, int flags)
 {
-	int i = 0;
-
 	/* If unmap_folio() uses try_to_migrate() on file, remove this check */
 	if (!folio_test_anon(folio))
 		return;
-	for (;;) {
+	do {
 		remove_migration_ptes(folio, folio, RMP_LOCKED | flags);
-		i += folio_nr_pages(folio);
-		if (i >= nr)
-			break;
-		folio = folio_next(folio);
-	}
+	} while ((folio = folio_next(folio)) != end_folio);
 }
 
 static void lru_add_split_folio(struct folio *folio, struct folio *new_folio,
@@ -4066,7 +4060,7 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
 	if (!ret && is_anon && !folio_is_device_private(folio))
 		remap_flags = RMP_USE_SHARED_ZEROPAGE;
 
-	remap_page(folio, 1 << old_order, remap_flags);
+	remap_page(folio, end_folio, remap_flags);
 
 	/*
 	 * Unlock all after-split folios except the one containing
-- 
2.34.1



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] mm/huge_memory: use end_folio to terminate anonymous folio remapping
  2025-11-27  2:24 [PATCH] mm/huge_memory: use end_folio to terminate anonymous folio remapping Wei Yang
@ 2025-11-27  6:30 ` Lorenzo Stoakes
  2025-11-27  7:22 ` David Hildenbrand (Red Hat)
  1 sibling, 0 replies; 4+ messages in thread
From: Lorenzo Stoakes @ 2025-11-27  6:30 UTC (permalink / raw)
  To: Wei Yang
  Cc: akpm, david, ziy, baolin.wang, Liam.Howlett, npache,
	ryan.roberts, dev.jain, baohua, lance.yang, linux-mm

Sorry Wei,

I know this is small, but can we not be doing these kinds of fiddly patches late
in -rc7 please?

Thanks, Lorenzo

On Thu, Nov 27, 2025 at 02:24:36AM +0000, Wei Yang wrote:
> After splitting a large folio, it is necessary to remap the resulting
> anonymous folios.
>
> The current implementation determines the end of the remapping process
> by counting the number of pages that have been processed.
>
> Since the final folio in the sequence, end_folio, is already known and
> tracked, this commit refactors the remapping loop to leverage end_folio
> as the termination marker.
>
> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
> Cc: Zi Yan <ziy@nvidia.com>
> ---
>  mm/huge_memory.c | 14 ++++----------
>  1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 553bfa961fce..afc7b2f91e99 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3414,20 +3414,14 @@ bool unmap_huge_pmd_locked(struct vm_area_struct *vma, unsigned long addr,
>  	return __discard_anon_folio_pmd_locked(vma, addr, pmdp, folio);
>  }
>
> -static void remap_page(struct folio *folio, unsigned long nr, int flags)
> +static void remap_page(struct folio *folio, struct folio *end_folio, int flags)
>  {
> -	int i = 0;
> -
>  	/* If unmap_folio() uses try_to_migrate() on file, remove this check */
>  	if (!folio_test_anon(folio))
>  		return;
> -	for (;;) {
> +	do {
>  		remove_migration_ptes(folio, folio, RMP_LOCKED | flags);
> -		i += folio_nr_pages(folio);
> -		if (i >= nr)
> -			break;
> -		folio = folio_next(folio);
> -	}
> +	} while ((folio = folio_next(folio)) != end_folio);
>  }
>
>  static void lru_add_split_folio(struct folio *folio, struct folio *new_folio,
> @@ -4066,7 +4060,7 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
>  	if (!ret && is_anon && !folio_is_device_private(folio))
>  		remap_flags = RMP_USE_SHARED_ZEROPAGE;
>
> -	remap_page(folio, 1 << old_order, remap_flags);
> +	remap_page(folio, end_folio, remap_flags);
>
>  	/*
>  	 * Unlock all after-split folios except the one containing
> --
> 2.34.1
>
>


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] mm/huge_memory: use end_folio to terminate anonymous folio remapping
  2025-11-27  2:24 [PATCH] mm/huge_memory: use end_folio to terminate anonymous folio remapping Wei Yang
  2025-11-27  6:30 ` Lorenzo Stoakes
@ 2025-11-27  7:22 ` David Hildenbrand (Red Hat)
  2025-11-27  8:54   ` Wei Yang
  1 sibling, 1 reply; 4+ messages in thread
From: David Hildenbrand (Red Hat) @ 2025-11-27  7:22 UTC (permalink / raw)
  To: Wei Yang, akpm, lorenzo.stoakes, ziy, baolin.wang, Liam.Howlett,
	npache, ryan.roberts, dev.jain, baohua, lance.yang
  Cc: linux-mm

On 11/27/25 03:24, Wei Yang wrote:
> After splitting a large folio, it is necessary to remap the resulting
> anonymous folios.
> 
> The current implementation determines the end of the remapping process
> by counting the number of pages that have been processed.
> 
> Since the final folio in the sequence, end_folio, is already known and
> tracked, this commit refactors the remapping loop to leverage end_folio
> as the termination marker.
> 
> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
> Cc: Zi Yan <ziy@nvidia.com>
> ---
>   mm/huge_memory.c | 14 ++++----------
>   1 file changed, 4 insertions(+), 10 deletions(-)
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 553bfa961fce..afc7b2f91e99 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3414,20 +3414,14 @@ bool unmap_huge_pmd_locked(struct vm_area_struct *vma, unsigned long addr,
>   	return __discard_anon_folio_pmd_locked(vma, addr, pmdp, folio);
>   }
>   
> -static void remap_page(struct folio *folio, unsigned long nr, int flags)
> +static void remap_page(struct folio *folio, struct folio *end_folio, int flags)
>   {
> -	int i = 0;
> -
>   	/* If unmap_folio() uses try_to_migrate() on file, remove this check */
>   	if (!folio_test_anon(folio))
>   		return;
> -	for (;;) {
> +	do {
>   		remove_migration_ptes(folio, folio, RMP_LOCKED | flags);
> -		i += folio_nr_pages(folio);
> -		if (i >= nr)
> -			break;
> -		folio = folio_next(folio);
> -	}
> +	} while ((folio = folio_next(folio)) != end_folio);

Rather ugly.

Nothing lost by just keeping "folio = folio_next(folio);" in the loop 
and focusing on what your patch documents.

But as Lorenzo said, the time for such cleanups is after most of the 
current stuff was merged in the upcoming merge window.

-- 
Cheers

David


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] mm/huge_memory: use end_folio to terminate anonymous folio remapping
  2025-11-27  7:22 ` David Hildenbrand (Red Hat)
@ 2025-11-27  8:54   ` Wei Yang
  0 siblings, 0 replies; 4+ messages in thread
From: Wei Yang @ 2025-11-27  8:54 UTC (permalink / raw)
  To: David Hildenbrand (Red Hat)
  Cc: Wei Yang, akpm, lorenzo.stoakes, ziy, baolin.wang, Liam.Howlett,
	npache, ryan.roberts, dev.jain, baohua, lance.yang, linux-mm

On Thu, Nov 27, 2025 at 08:22:26AM +0100, David Hildenbrand (Red Hat) wrote:
>On 11/27/25 03:24, Wei Yang wrote:
>> After splitting a large folio, it is necessary to remap the resulting
>> anonymous folios.
>> 
>> The current implementation determines the end of the remapping process
>> by counting the number of pages that have been processed.
>> 
>> Since the final folio in the sequence, end_folio, is already known and
>> tracked, this commit refactors the remapping loop to leverage end_folio
>> as the termination marker.
>> 
>> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>> Cc: Zi Yan <ziy@nvidia.com>
>> ---
>>   mm/huge_memory.c | 14 ++++----------
>>   1 file changed, 4 insertions(+), 10 deletions(-)
>> 
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index 553bfa961fce..afc7b2f91e99 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -3414,20 +3414,14 @@ bool unmap_huge_pmd_locked(struct vm_area_struct *vma, unsigned long addr,
>>   	return __discard_anon_folio_pmd_locked(vma, addr, pmdp, folio);
>>   }
>> -static void remap_page(struct folio *folio, unsigned long nr, int flags)
>> +static void remap_page(struct folio *folio, struct folio *end_folio, int flags)
>>   {
>> -	int i = 0;
>> -
>>   	/* If unmap_folio() uses try_to_migrate() on file, remove this check */
>>   	if (!folio_test_anon(folio))
>>   		return;
>> -	for (;;) {
>> +	do {
>>   		remove_migration_ptes(folio, folio, RMP_LOCKED | flags);
>> -		i += folio_nr_pages(folio);
>> -		if (i >= nr)
>> -			break;
>> -		folio = folio_next(folio);
>> -	}
>> +	} while ((folio = folio_next(folio)) != end_folio);
>
>Rather ugly.
>
>Nothing lost by just keeping "folio = folio_next(folio);" in the loop and
>focusing on what your patch documents.
>
>But as Lorenzo said, the time for such cleanups is after most of the current
>stuff was merged in the upcoming merge window.

Sure.

>
>-- 
>Cheers
>
>David

-- 
Wei Yang
Help you, Help me


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2025-11-27  8:54 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-11-27  2:24 [PATCH] mm/huge_memory: use end_folio to terminate anonymous folio remapping Wei Yang
2025-11-27  6:30 ` Lorenzo Stoakes
2025-11-27  7:22 ` David Hildenbrand (Red Hat)
2025-11-27  8:54   ` Wei Yang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox