Messages in this thread | | | Subject | Re: [PATCH v3 1/6] mm: migrate: do not migrate HugeTLB page whose refcount is one | From | David Hildenbrand <> | Date | Tue, 12 Jan 2021 12:11:21 +0100 |
| |
On 12.01.21 12:00, David Hildenbrand wrote: > On 10.01.21 13:40, Muchun Song wrote: >> 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 <songmuchun@bytedance.com> >> Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com> >> Acked-by: Yang Shi <shy828301@gmail.com> >> --- >> 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? >
To be more precise:
a) We don't have dissolve_free_huge_pages() calls on the alloc_contig_range() path. So we *need* migration IIUC.
b) dissolve_free_huge_pages() will fail if going below the reservation. In that case we really want to migrate free pages. This even applies to memory offlining.
Either I am missing something important or this patch is more dangerous than it looks like.
-- Thanks,
David / dhildenb
| |