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 <[email protected]> >> Reviewed-by: Mike Kravetz <[email protected]> >> Acked-by: Yang Shi <[email protected]> >> --- >> 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
