[PATCH 0/3] mm/migrate: preparatory cleanups for batch copy and offload

[PATCH 0/3] mm/migrate: preparatory cleanups for batch copy and offload

[Shivank Garg]

This is a small set of mm/migrate cleanups split out of the batch-copy
and offload RFC [1], so they can be reviewed and merged independently
ahead of that larger series.

No functional change intended.

[1] https://lore.kernel.org/all/20260428155043.39251-2-shivankg@amd.com

Signed-off-by: Shivank Garg <shivankg@amd.com>
---
Shivank Garg (3):
      mm/migrate: rename page to folio leftovers
      mm/migrate: fix stale list name in migrate_folios_move() comment
      mm/migrate: use migrate_info field instead of private

 include/linux/mm_types.h |  1 +
 mm/migrate.c             | 27 ++++++++++++---------------
 2 files changed, 13 insertions(+), 15 deletions(-)
---
base-commit: 4edcdefd4083ae04b1a5656f4be6cd83ae919ef4
change-id: 20260626-migrate-cleanups-prep-77a0ad340cc6

Best regards,
-- 
Shivank Garg <shivankg@amd.com>

[PATCH 1/3] mm/migrate: rename page to folio leftovers

[Shivank Garg]

Rename migrate_folio_undo_src()'s page_was_mapped parameter to
folio_was_mapped, matching FOLIO_WAS_MAPPED naming.

Also fix migrate_folio() kerneldoc to say "folio" instead of "page".

Suggested-by: Dev Jain <dev.jain@arm.com>
Signed-off-by: Shivank Garg <shivankg@amd.com>
---
 mm/migrate.c | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/mm/migrate.c b/mm/migrate.c
index d9b23909d716..dd7dbd8d84a0 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -884,7 +884,7 @@ static int __migrate_folio(struct address_space *mapping, struct folio *dst,
  * @mapping: The address_space containing the folio.
  * @dst: The folio to migrate the data to.
  * @src: The folio containing the current data.
- * @mode: How to migrate the page.
+ * @mode: How to migrate the folio.
  *
  * Common logic to directly migrate a single LRU folio suitable for
  * folios that do not have private data.
@@ -1157,13 +1157,10 @@ static void __migrate_folio_extract(struct folio *dst,
 }
 
 /* Restore the source folio to the original state upon failure */
-static void migrate_folio_undo_src(struct folio *src,
-				   int page_was_mapped,
-				   struct anon_vma *anon_vma,
-				   bool locked,
-				   struct list_head *ret)
+static void migrate_folio_undo_src(struct folio *src, int folio_was_mapped,
+		struct anon_vma *anon_vma, bool locked, struct list_head *ret)
 {
-	if (page_was_mapped)
+	if (folio_was_mapped)
 		remove_migration_ptes(src, src, 0);
 	/* Drop an anon_vma reference if we took one */
 	if (anon_vma)

-- 
2.43.0

Re: [PATCH 1/3] mm/migrate: rename page to folio leftovers

[David Hildenbrand (Arm)]

On 6/26/26 11:37, Shivank Garg wrote:
> Rename migrate_folio_undo_src()'s page_was_mapped parameter to
> folio_was_mapped, matching FOLIO_WAS_MAPPED naming.
> 
> Also fix migrate_folio() kerneldoc to say "folio" instead of "page".
> 
> Suggested-by: Dev Jain <dev.jain@arm.com>
> Signed-off-by: Shivank Garg <shivankg@amd.com>
> ---
>  mm/migrate.c | 11 ++++-------
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/mm/migrate.c b/mm/migrate.c
> index d9b23909d716..dd7dbd8d84a0 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -884,7 +884,7 @@ static int __migrate_folio(struct address_space *mapping, struct folio *dst,
>   * @mapping: The address_space containing the folio.
>   * @dst: The folio to migrate the data to.
>   * @src: The folio containing the current data.
> - * @mode: How to migrate the page.
> + * @mode: How to migrate the folio.
>   *
>   * Common logic to directly migrate a single LRU folio suitable for
>   * folios that do not have private data.
> @@ -1157,13 +1157,10 @@ static void __migrate_folio_extract(struct folio *dst,
>  }
>  
>  /* Restore the source folio to the original state upon failure */
> -static void migrate_folio_undo_src(struct folio *src,
> -				   int page_was_mapped,
> -				   struct anon_vma *anon_vma,
> -				   bool locked,
> -				   struct list_head *ret)
> +static void migrate_folio_undo_src(struct folio *src, int folio_was_mapped,
> +		struct anon_vma *anon_vma, bool locked, struct list_head *ret)
>  {
> -	if (page_was_mapped)
> +	if (folio_was_mapped)

Why not "was_mapped" given that folio is part of the function name?

(it's also not "folio_locked") :)

-- 
Cheers,

David

Re: [PATCH 1/3] mm/migrate: rename page to folio leftovers

[Garg, Shivank]

On 6/26/2026 9:40 PM, David Hildenbrand (Arm) wrote:
> On 6/26/26 11:37, Shivank Garg wrote:
>> Rename migrate_folio_undo_src()'s page_was_mapped parameter to
>> folio_was_mapped, matching FOLIO_WAS_MAPPED naming.
>>
>> Also fix migrate_folio() kerneldoc to say "folio" instead of "page".
>>
>> Suggested-by: Dev Jain <dev.jain@arm.com>
>> Signed-off-by: Shivank Garg <shivankg@amd.com>
>> ---
>>  mm/migrate.c | 11 ++++-------
>>  1 file changed, 4 insertions(+), 7 deletions(-)
>>
>> diff --git a/mm/migrate.c b/mm/migrate.c
>> index d9b23909d716..dd7dbd8d84a0 100644
>> --- a/mm/migrate.c
>> +++ b/mm/migrate.c
>> @@ -884,7 +884,7 @@ static int __migrate_folio(struct address_space *mapping, struct folio *dst,
>>   * @mapping: The address_space containing the folio.
>>   * @dst: The folio to migrate the data to.
>>   * @src: The folio containing the current data.
>> - * @mode: How to migrate the page.
>> + * @mode: How to migrate the folio.
>>   *
>>   * Common logic to directly migrate a single LRU folio suitable for
>>   * folios that do not have private data.
>> @@ -1157,13 +1157,10 @@ static void __migrate_folio_extract(struct folio *dst,
>>  }
>>  
>>  /* Restore the source folio to the original state upon failure */
>> -static void migrate_folio_undo_src(struct folio *src,
>> -				   int page_was_mapped,
>> -				   struct anon_vma *anon_vma,
>> -				   bool locked,
>> -				   struct list_head *ret)
>> +static void migrate_folio_undo_src(struct folio *src, int folio_was_mapped,
>> +		struct anon_vma *anon_vma, bool locked, struct list_head *ret)
>>  {
>> -	if (page_was_mapped)
>> +	if (folio_was_mapped)
> 
> Why not "was_mapped" given that folio is part of the function name?
> 
> (it's also not "folio_locked") :)
> 

yes, makes sense. I'll use was_mapped.

While here, what's your opinion on unmap_and_move_huge_page()?
It also has local variable named page_was_mapped even though the function
is fully folio-based. The function name and comments still have "page".

Thanks,
Shivank

Re: [PATCH 1/3] mm/migrate: rename page to folio leftovers

[David Hildenbrand (Arm)]

On 6/26/26 18:42, Garg, Shivank wrote:
> 
> 
> On 6/26/2026 9:40 PM, David Hildenbrand (Arm) wrote:
>> On 6/26/26 11:37, Shivank Garg wrote:
>>> Rename migrate_folio_undo_src()'s page_was_mapped parameter to
>>> folio_was_mapped, matching FOLIO_WAS_MAPPED naming.
>>>
>>> Also fix migrate_folio() kerneldoc to say "folio" instead of "page".
>>>
>>> Suggested-by: Dev Jain <dev.jain@arm.com>
>>> Signed-off-by: Shivank Garg <shivankg@amd.com>
>>> ---
>>>  mm/migrate.c | 11 ++++-------
>>>  1 file changed, 4 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/mm/migrate.c b/mm/migrate.c
>>> index d9b23909d716..dd7dbd8d84a0 100644
>>> --- a/mm/migrate.c
>>> +++ b/mm/migrate.c
>>> @@ -884,7 +884,7 @@ static int __migrate_folio(struct address_space *mapping, struct folio *dst,
>>>   * @mapping: The address_space containing the folio.
>>>   * @dst: The folio to migrate the data to.
>>>   * @src: The folio containing the current data.
>>> - * @mode: How to migrate the page.
>>> + * @mode: How to migrate the folio.
>>>   *
>>>   * Common logic to directly migrate a single LRU folio suitable for
>>>   * folios that do not have private data.
>>> @@ -1157,13 +1157,10 @@ static void __migrate_folio_extract(struct folio *dst,
>>>  }
>>>  
>>>  /* Restore the source folio to the original state upon failure */
>>> -static void migrate_folio_undo_src(struct folio *src,
>>> -				   int page_was_mapped,
>>> -				   struct anon_vma *anon_vma,
>>> -				   bool locked,
>>> -				   struct list_head *ret)
>>> +static void migrate_folio_undo_src(struct folio *src, int folio_was_mapped,
>>> +		struct anon_vma *anon_vma, bool locked, struct list_head *ret)
>>>  {
>>> -	if (page_was_mapped)
>>> +	if (folio_was_mapped)
>>
>> Why not "was_mapped" given that folio is part of the function name?
>>
>> (it's also not "folio_locked") :)
>>
> 
> yes, makes sense. I'll use was_mapped.
> 
> While here, what's your opinion on unmap_and_move_huge_page()?
> It also has local variable named page_was_mapped even though the function
> is fully folio-based. The function name and comments still have "page".

Ah, yeah ... please fix that.

And while at it, rename it to "unmap_and_move_hugetlb_folio". Thx :)

-- 
Cheers,

David

[PATCH 2/3] mm/migrate: fix stale list name in migrate_folios_move() comment

[Shivank Garg]

The return-value description in migrate_folios_move() still refers to
unmap_folios, but that list no longer exists. Update this name to
src_folios.

Signed-off-by: Shivank Garg <shivankg@amd.com>
---
 mm/migrate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/migrate.c b/mm/migrate.c
index dd7dbd8d84a0..84b4c24f9dac 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1738,7 +1738,7 @@ static void migrate_folios_move(struct list_head *src_folios,
 		/*
 		 * The rules are:
 		 *	0: folio will be freed
-		 *	-EAGAIN: stay on the unmap_folios list
+		 *	-EAGAIN: stay on the src_folios list
 		 *	Other errno: put on ret_folios list
 		 */
 		switch (rc) {

-- 
2.43.0

Re: [PATCH 2/3] mm/migrate: fix stale list name in migrate_folios_move() comment

[David Hildenbrand (Arm)]

On 6/26/26 11:37, Shivank Garg wrote:
> The return-value description in migrate_folios_move() still refers to
> unmap_folios, but that list no longer exists. Update this name to
> src_folios.
> 
> Signed-off-by: Shivank Garg <shivankg@amd.com>
> ---
>  mm/migrate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/migrate.c b/mm/migrate.c
> index dd7dbd8d84a0..84b4c24f9dac 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -1738,7 +1738,7 @@ static void migrate_folios_move(struct list_head *src_folios,
>  		/*
>  		 * The rules are:
>  		 *	0: folio will be freed
> -		 *	-EAGAIN: stay on the unmap_folios list
> +		 *	-EAGAIN: stay on the src_folios list
>  		 *	Other errno: put on ret_folios list
>  		 */
>  		switch (rc) {
> 

Acked-by: David Hildenbrand (Arm) <david@kernel.org>

-- 
Cheers,

David

Re: [PATCH 2/3] mm/migrate: fix stale list name in migrate_folios_move() comment

[Zi Yan]

On Fri Jun 26, 2026 at 5:37 AM EDT, Shivank Garg wrote:
> The return-value description in migrate_folios_move() still refers to
> unmap_folios, but that list no longer exists. Update this name to
> src_folios.
>
> Signed-off-by: Shivank Garg <shivankg@amd.com>
> ---
>  mm/migrate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
LGTM.

Reviewed-by: Zi Yan <ziy@nvidia.com>


-- 
Best Regards,
Yan, Zi

[PATCH 3/3] mm/migrate: use migrate_info field instead of private

[Shivank Garg]

Add an unsigned long migrate_info member to the struct folio union and
use it to store migration state (anon_vma pointer and FOLIO_WAS_*
markers) instead of using folio->private. While at it, switch to bitwise
OR.

No functional change.

Suggested-by: David Hildenbrand <david@kernel.org>
Reviewed-by: Jonathan Cameron <jic23@kernel.org>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Reviewed-by: Huang Ying <ying.huang@linux.alibaba.com>
Signed-off-by: Shivank Garg <shivankg@amd.com>
---
 include/linux/mm_types.h |  1 +
 mm/migrate.c             | 14 +++++++-------
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index b18c2b2e7d2c..ae9bca4eda5c 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -427,6 +427,7 @@ struct folio {
 			union {
 				void *private;
 				swp_entry_t swap;
+				unsigned long migrate_info;
 			};
 			atomic_t _mapcount;
 			atomic_t _refcount;
diff --git a/mm/migrate.c b/mm/migrate.c
index 84b4c24f9dac..7a83032a14b5 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1130,7 +1130,7 @@ static int move_to_new_folio(struct folio *dst, struct folio *src,
 }
 
 /*
- * To record some information during migration, we use unused private
+ * To record some information during migration, we use the migrate_info
  * field of struct folio of the newly allocated destination folio.
  * This is safe because nobody is using it except us.
  */
@@ -1143,17 +1143,17 @@ enum {
 static void __migrate_folio_record(struct folio *dst,
 		int old_folio_state, struct anon_vma *anon_vma)
 {
-	dst->private = (void *)anon_vma + old_folio_state;
+	dst->migrate_info = (unsigned long)anon_vma | old_folio_state;
 }
 
 static void __migrate_folio_extract(struct folio *dst,
 		int *old_folio_state, struct anon_vma **anon_vmap)
 {
-	unsigned long private = (unsigned long)dst->private;
+	unsigned long info = dst->migrate_info;
 
-	*anon_vmap = (struct anon_vma *)(private & ~FOLIO_OLD_STATES);
-	*old_folio_state = private & FOLIO_OLD_STATES;
-	dst->private = NULL;
+	*anon_vmap = (struct anon_vma *)(info & ~FOLIO_OLD_STATES);
+	*old_folio_state = info & FOLIO_OLD_STATES;
+	dst->migrate_info = 0;
 }
 
 /* Restore the source folio to the original state upon failure */
@@ -1214,7 +1214,7 @@ static int migrate_folio_unmap(new_folio_t get_new_folio,
 		return -ENOMEM;
 	*dstp = dst;
 
-	dst->private = NULL;
+	dst->migrate_info = 0;
 
 	if (!folio_trylock(src)) {
 		if (mode == MIGRATE_ASYNC)

-- 
2.43.0

Re: [PATCH 3/3] mm/migrate: use migrate_info field instead of private

[Zi Yan]

On Fri Jun 26, 2026 at 5:37 AM EDT, Shivank Garg wrote:
> Add an unsigned long migrate_info member to the struct folio union and
> use it to store migration state (anon_vma pointer and FOLIO_WAS_*
> markers) instead of using folio->private. While at it, switch to bitwise
> OR.
>
> No functional change.
>
> Suggested-by: David Hildenbrand <david@kernel.org>
> Reviewed-by: Jonathan Cameron <jic23@kernel.org>
> Acked-by: David Hildenbrand (Arm) <david@kernel.org>
> Reviewed-by: Huang Ying <ying.huang@linux.alibaba.com>
> Signed-off-by: Shivank Garg <shivankg@amd.com>
> ---
>  include/linux/mm_types.h |  1 +
>  mm/migrate.c             | 14 +++++++-------
>  2 files changed, 8 insertions(+), 7 deletions(-)
>
LGTM.
Acked-by: Zi Yan <ziy@nvidia.com>

-- 
Best Regards,
Yan, Zi