[PATCH v1 09/29] mm/migrate: factor out movable_ops page handling into migrate_movable_ops_page()

David Hildenbrand posted 29 patches 3 months, 1 week ago
There is a newer version of this series
[PATCH v1 09/29] mm/migrate: factor out movable_ops page handling into migrate_movable_ops_page()
Posted by David Hildenbrand 3 months, 1 week ago
Let's factor it out, simplifying the calling code.

The assumption is that flush_dcache_page() is not required for
movable_ops pages: as documented for flush_dcache_folio(), it really
only applies when the kernel wrote to pagecache pages / pages in
highmem. movable_ops callbacks should be handling flushing
caches if ever required.

Note that we can now change folio_mapping_flags() to folio_test_anon()
to make it clearer, because movable_ops pages will never take that path.

Reviewed-by: Zi Yan <ziy@nvidia.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
---
 mm/migrate.c | 82 ++++++++++++++++++++++++++++------------------------
 1 file changed, 45 insertions(+), 37 deletions(-)

diff --git a/mm/migrate.c b/mm/migrate.c
index d97f7cd137e63..0898ddd2f661f 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -159,6 +159,45 @@ static void putback_movable_ops_page(struct page *page)
 	folio_put(folio);
 }
 
+/**
+ * migrate_movable_ops_page - migrate an isolated movable_ops page
+ * @page: The isolated page.
+ *
+ * Migrate an isolated movable_ops page.
+ *
+ * If the src page was already released by its owner, the src page is
+ * un-isolated (putback) and migration succeeds; the migration core will be the
+ * owner of both pages.
+ *
+ * If the src page was not released by its owner and the migration was
+ * successful, the owner of the src page and the dst page are swapped and
+ * the src page is un-isolated.
+ *
+ * If migration fails, the ownership stays unmodified and the src page
+ * remains isolated: migration may be retried later or the page can be putback.
+ *
+ * TODO: migration core will treat both pages as folios and lock them before
+ * this call to unlock them after this call. Further, the folio refcounts on
+ * src and dst are also released by migration core. These pages will not be
+ * folios in the future, so that must be reworked.
+ *
+ * Returns MIGRATEPAGE_SUCCESS on success, otherwise a negative error
+ * code.
+ */
+static int migrate_movable_ops_page(struct page *dst, struct page *src,
+		enum migrate_mode mode)
+{
+	int rc = MIGRATEPAGE_SUCCESS;
+
+	VM_WARN_ON_ONCE_PAGE(!PageIsolated(src), src);
+	/* If the page was released by it's owner, there is nothing to do. */
+	if (PageMovable(src))
+		rc = page_movable_ops(src)->migrate_page(dst, src, mode);
+	if (rc == MIGRATEPAGE_SUCCESS)
+		ClearPageIsolated(src);
+	return rc;
+}
+
 /*
  * Put previously isolated pages back onto the appropriate lists
  * from where they were once taken off for compaction/migration.
@@ -1023,51 +1062,20 @@ static int move_to_new_folio(struct folio *dst, struct folio *src,
 								mode);
 		else
 			rc = fallback_migrate_folio(mapping, dst, src, mode);
-	} else {
-		const struct movable_operations *mops;
 
-		/*
-		 * In case of non-lru page, it could be released after
-		 * isolation step. In that case, we shouldn't try migration.
-		 */
-		VM_BUG_ON_FOLIO(!folio_test_isolated(src), src);
-		if (!folio_test_movable(src)) {
-			rc = MIGRATEPAGE_SUCCESS;
-			folio_clear_isolated(src);
+		if (rc != MIGRATEPAGE_SUCCESS)
 			goto out;
-		}
-
-		mops = folio_movable_ops(src);
-		rc = mops->migrate_page(&dst->page, &src->page, mode);
-		WARN_ON_ONCE(rc == MIGRATEPAGE_SUCCESS &&
-				!folio_test_isolated(src));
-	}
-
-	/*
-	 * When successful, old pagecache src->mapping must be cleared before
-	 * src is freed; but stats require that PageAnon be left as PageAnon.
-	 */
-	if (rc == MIGRATEPAGE_SUCCESS) {
-		if (__folio_test_movable(src)) {
-			VM_BUG_ON_FOLIO(!folio_test_isolated(src), src);
-
-			/*
-			 * We clear PG_movable under page_lock so any compactor
-			 * cannot try to migrate this page.
-			 */
-			folio_clear_isolated(src);
-		}
-
 		/*
-		 * Anonymous and movable src->mapping will be cleared by
-		 * free_pages_prepare so don't reset it here for keeping
-		 * the type to work PageAnon, for example.
+		 * For pagecache folios, src->mapping must be cleared before src
+		 * is freed. Anonymous folios must stay anonymous until freed.
 		 */
-		if (!folio_mapping_flags(src))
+		if (!folio_test_anon(src))
 			src->mapping = NULL;
 
 		if (likely(!folio_is_zone_device(dst)))
 			flush_dcache_folio(dst);
+	} else {
+		rc = migrate_movable_ops_page(&dst->page, &src->page, mode);
 	}
 out:
 	return rc;
-- 
2.49.0
Re: [PATCH v1 09/29] mm/migrate: factor out movable_ops page handling into migrate_movable_ops_page()
Posted by Harry Yoo 3 months, 1 week ago
On Mon, Jun 30, 2025 at 02:59:50PM +0200, David Hildenbrand wrote:
> Let's factor it out, simplifying the calling code.
> 
> The assumption is that flush_dcache_page() is not required for
> movable_ops pages: as documented for flush_dcache_folio(), it really
> only applies when the kernel wrote to pagecache pages / pages in
> highmem. movable_ops callbacks should be handling flushing
> caches if ever required.
> 
> Note that we can now change folio_mapping_flags() to folio_test_anon()
> to make it clearer, because movable_ops pages will never take that path.
> 
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---

Looks correct to me.
Reviewed-by: Harry Yoo <harry.yoo@oracle.com>

-- 
Cheers,
Harry / Hyeonggon
Re: [PATCH v1 09/29] mm/migrate: factor out movable_ops page handling into migrate_movable_ops_page()
Posted by Lorenzo Stoakes 3 months, 1 week ago
On Mon, Jun 30, 2025 at 02:59:50PM +0200, David Hildenbrand wrote:
> Let's factor it out, simplifying the calling code.
>
> The assumption is that flush_dcache_page() is not required for
> movable_ops pages: as documented for flush_dcache_folio(), it really
> only applies when the kernel wrote to pagecache pages / pages in
> highmem. movable_ops callbacks should be handling flushing
> caches if ever required.

But we've enot changed this have we? The flush_dcache_folio() invocation seems
to happen the same way now as before? Did I miss something?

>
> Note that we can now change folio_mapping_flags() to folio_test_anon()
> to make it clearer, because movable_ops pages will never take that path.
>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>

Have scrutinised this a lot and it seems correct to me, so:

Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>

> ---
>  mm/migrate.c | 82 ++++++++++++++++++++++++++++------------------------
>  1 file changed, 45 insertions(+), 37 deletions(-)
>
> diff --git a/mm/migrate.c b/mm/migrate.c
> index d97f7cd137e63..0898ddd2f661f 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -159,6 +159,45 @@ static void putback_movable_ops_page(struct page *page)
>  	folio_put(folio);
>  }
>
> +/**
> + * migrate_movable_ops_page - migrate an isolated movable_ops page
> + * @page: The isolated page.
> + *
> + * Migrate an isolated movable_ops page.
> + *
> + * If the src page was already released by its owner, the src page is
> + * un-isolated (putback) and migration succeeds; the migration core will be the
> + * owner of both pages.
> + *
> + * If the src page was not released by its owner and the migration was
> + * successful, the owner of the src page and the dst page are swapped and
> + * the src page is un-isolated.
> + *
> + * If migration fails, the ownership stays unmodified and the src page
> + * remains isolated: migration may be retried later or the page can be putback.
> + *
> + * TODO: migration core will treat both pages as folios and lock them before
> + * this call to unlock them after this call. Further, the folio refcounts on
> + * src and dst are also released by migration core. These pages will not be
> + * folios in the future, so that must be reworked.
> + *
> + * Returns MIGRATEPAGE_SUCCESS on success, otherwise a negative error
> + * code.
> + */

Love these comments you're adding!!

> +static int migrate_movable_ops_page(struct page *dst, struct page *src,
> +		enum migrate_mode mode)
> +{
> +	int rc = MIGRATEPAGE_SUCCESS;

Maybe worth asserting src, dst locking?

> +
> +	VM_WARN_ON_ONCE_PAGE(!PageIsolated(src), src);
> +	/* If the page was released by it's owner, there is nothing to do. */
> +	if (PageMovable(src))
> +		rc = page_movable_ops(src)->migrate_page(dst, src, mode);
> +	if (rc == MIGRATEPAGE_SUCCESS)
> +		ClearPageIsolated(src);
> +	return rc;
> +}
> +
>  /*
>   * Put previously isolated pages back onto the appropriate lists
>   * from where they were once taken off for compaction/migration.
> @@ -1023,51 +1062,20 @@ static int move_to_new_folio(struct folio *dst, struct folio *src,
>  								mode);
>  		else
>  			rc = fallback_migrate_folio(mapping, dst, src, mode);
> -	} else {
> -		const struct movable_operations *mops;
>
> -		/*
> -		 * In case of non-lru page, it could be released after
> -		 * isolation step. In that case, we shouldn't try migration.
> -		 */
> -		VM_BUG_ON_FOLIO(!folio_test_isolated(src), src);
> -		if (!folio_test_movable(src)) {
> -			rc = MIGRATEPAGE_SUCCESS;
> -			folio_clear_isolated(src);
> +		if (rc != MIGRATEPAGE_SUCCESS)
>  			goto out;
> -		}
> -
> -		mops = folio_movable_ops(src);
> -		rc = mops->migrate_page(&dst->page, &src->page, mode);
> -		WARN_ON_ONCE(rc == MIGRATEPAGE_SUCCESS &&
> -				!folio_test_isolated(src));
> -	}
> -
> -	/*
> -	 * When successful, old pagecache src->mapping must be cleared before
> -	 * src is freed; but stats require that PageAnon be left as PageAnon.
> -	 */
> -	if (rc == MIGRATEPAGE_SUCCESS) {
> -		if (__folio_test_movable(src)) {
> -			VM_BUG_ON_FOLIO(!folio_test_isolated(src), src);
> -
> -			/*
> -			 * We clear PG_movable under page_lock so any compactor
> -			 * cannot try to migrate this page.
> -			 */
> -			folio_clear_isolated(src);
> -		}
> -
>  		/*
> -		 * Anonymous and movable src->mapping will be cleared by
> -		 * free_pages_prepare so don't reset it here for keeping
> -		 * the type to work PageAnon, for example.
> +		 * For pagecache folios, src->mapping must be cleared before src
> +		 * is freed. Anonymous folios must stay anonymous until freed.
>  		 */
> -		if (!folio_mapping_flags(src))
> +		if (!folio_test_anon(src))
>  			src->mapping = NULL;
>
>  		if (likely(!folio_is_zone_device(dst)))
>  			flush_dcache_folio(dst);
> +	} else {
> +		rc = migrate_movable_ops_page(&dst->page, &src->page, mode);
>  	}
>  out:
>  	return rc;
> --
> 2.49.0
>
Re: [PATCH v1 09/29] mm/migrate: factor out movable_ops page handling into migrate_movable_ops_page()
Posted by David Hildenbrand 3 months, 1 week ago
On 30.06.25 19:05, Lorenzo Stoakes wrote:
> On Mon, Jun 30, 2025 at 02:59:50PM +0200, David Hildenbrand wrote:
>> Let's factor it out, simplifying the calling code.
>>
>> The assumption is that flush_dcache_page() is not required for
>> movable_ops pages: as documented for flush_dcache_folio(), it really
>> only applies when the kernel wrote to pagecache pages / pages in
>> highmem. movable_ops callbacks should be handling flushing
>> caches if ever required.
> 
> But we've enot changed this have we? The flush_dcache_folio() invocation seems
> to happen the same way now as before? Did I miss something?

I think, before this change we would have called it also for movable_ops 
pages


if (rc == MIGRATEPAGE_SUCCESS) {
	if (__folio_test_movable(src)) {
		...
	}

	...

	if (likely(!folio_is_zone_device(dst)))
		flush_dcache_folio(dst);
}

Now, we no longer do that for movable_ops pages.

For balloon pages, we're not copying anything, so we never possibly have 
to flush the dcache.

For zsmalloc, we do the copy in zs_object_copy() through kmap_local.

I think we could have HIGHMEM, so I wonder if we should just do a 
flush_dcache_page() in zs_object_copy().

At least, staring at highmem.h with memcpy_to_page(), it looks like that 
might be the right thing to do.


So likely I'll add a patch before this one that will do the 
flush_dcache_page() in there.

> 
>>
>> Note that we can now change folio_mapping_flags() to folio_test_anon()
>> to make it clearer, because movable_ops pages will never take that path.
>>
>> Reviewed-by: Zi Yan <ziy@nvidia.com>
>> Signed-off-by: David Hildenbrand <david@redhat.com>
> 
> Have scrutinised this a lot and it seems correct to me, so:
> 
> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> 
>> ---
>>   mm/migrate.c | 82 ++++++++++++++++++++++++++++------------------------
>>   1 file changed, 45 insertions(+), 37 deletions(-)
>>
>> diff --git a/mm/migrate.c b/mm/migrate.c
>> index d97f7cd137e63..0898ddd2f661f 100644
>> --- a/mm/migrate.c
>> +++ b/mm/migrate.c
>> @@ -159,6 +159,45 @@ static void putback_movable_ops_page(struct page *page)
>>   	folio_put(folio);
>>   }
>>
>> +/**
>> + * migrate_movable_ops_page - migrate an isolated movable_ops page
>> + * @page: The isolated page.
>> + *
>> + * Migrate an isolated movable_ops page.
>> + *
>> + * If the src page was already released by its owner, the src page is
>> + * un-isolated (putback) and migration succeeds; the migration core will be the
>> + * owner of both pages.
>> + *
>> + * If the src page was not released by its owner and the migration was
>> + * successful, the owner of the src page and the dst page are swapped and
>> + * the src page is un-isolated.
>> + *
>> + * If migration fails, the ownership stays unmodified and the src page
>> + * remains isolated: migration may be retried later or the page can be putback.
>> + *
>> + * TODO: migration core will treat both pages as folios and lock them before
>> + * this call to unlock them after this call. Further, the folio refcounts on
>> + * src and dst are also released by migration core. These pages will not be
>> + * folios in the future, so that must be reworked.
>> + *
>> + * Returns MIGRATEPAGE_SUCCESS on success, otherwise a negative error
>> + * code.
>> + */
> 
> Love these comments you're adding!!
> 
>> +static int migrate_movable_ops_page(struct page *dst, struct page *src,
>> +		enum migrate_mode mode)
>> +{
>> +	int rc = MIGRATEPAGE_SUCCESS;
> 
> Maybe worth asserting src, dst locking?

We do have these sanity checks right now in move_to_new_folio() already. 
(next patch moves it further out)

Not sure how reasonable these sanity checks are in these internal 
helpers: E.g., after we called move_to_new_folio() we will unlock both 
folios, which should blow up if the folios wouldn't be locked.

-- 
Cheers,

David / dhildenb
Re: [PATCH v1 09/29] mm/migrate: factor out movable_ops page handling into migrate_movable_ops_page()
Posted by David Hildenbrand 3 months, 1 week ago
On 01.07.25 11:24, David Hildenbrand wrote:
> On 30.06.25 19:05, Lorenzo Stoakes wrote:
>> On Mon, Jun 30, 2025 at 02:59:50PM +0200, David Hildenbrand wrote:
>>> Let's factor it out, simplifying the calling code.
>>>
>>> The assumption is that flush_dcache_page() is not required for
>>> movable_ops pages: as documented for flush_dcache_folio(), it really
>>> only applies when the kernel wrote to pagecache pages / pages in
>>> highmem. movable_ops callbacks should be handling flushing
>>> caches if ever required.
>>
>> But we've enot changed this have we? The flush_dcache_folio() invocation seems
>> to happen the same way now as before? Did I miss something?
> 
> I think, before this change we would have called it also for movable_ops
> pages
> 
> 
> if (rc == MIGRATEPAGE_SUCCESS) {
> 	if (__folio_test_movable(src)) {
> 		...
> 	}
> 
> 	...
> 
> 	if (likely(!folio_is_zone_device(dst)))
> 		flush_dcache_folio(dst);
> }
> 
> Now, we no longer do that for movable_ops pages.
> 
> For balloon pages, we're not copying anything, so we never possibly have
> to flush the dcache.
> 
> For zsmalloc, we do the copy in zs_object_copy() through kmap_local.
> 
> I think we could have HIGHMEM, so I wonder if we should just do a
> flush_dcache_page() in zs_object_copy().
> 
> At least, staring at highmem.h with memcpy_to_page(), it looks like that
> might be the right thing to do.
> 
> 
> So likely I'll add a patch before this one that will do the
> flush_dcache_page() in there.

But reading the docs again:

"This routine need only be called for page cache pages which can 
potentially ever be mapped into the address space of a user process."

So, not required IIUC. I'll clarify in the patch description.

-- 
Cheers,

David / dhildenb