Thread (39 messages) 39 messages, 4 authors, 2021-01-12

Re: [PATCH v3 1/6] mm: migrate: do not migrate HugeTLB page whose refcount is one

From: David Hildenbrand <hidden>
Date: 2021-01-12 11:01:41
Also in: lkml

On 10.01.21 13:40, Muchun Song wrote:
quoted hunk ↗ jump to hunk
If the refcount is one when it is migrated, it means that the page
was freed from under us. So we are done and do not need to migrate.

This optimization is consistent with the regular pages, just like
unmap_and_move() does.

Signed-off-by: Muchun Song <redacted>
Reviewed-by: Mike Kravetz <redacted>
Acked-by: Yang Shi <redacted>
---
 mm/migrate.c | 6 ++++++
 1 file changed, 6 insertions(+)
diff --git a/mm/migrate.c b/mm/migrate.c
index 4385f2fb5d18..a6631c4eb6a6 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1279,6 +1279,12 @@ static int unmap_and_move_huge_page(new_page_t get_new_page,
 		return -ENOSYS;
 	}
 
+	if (page_count(hpage) == 1) {
+		/* page was freed from under us. So we are done. */
+		putback_active_hugepage(hpage);
+		return MIGRATEPAGE_SUCCESS;
+	}
+
 	new_hpage = get_new_page(hpage, private);
 	if (!new_hpage)
 		return -ENOMEM;
Question: What if called via alloc_contig_range() where we even want to
"migrate" free pages, meaning, relocate it?

-- 
Thanks,

David / dhildenb

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help