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@xxxxxxxxxxxxx>
>> Reviewed-by: Mike Kravetz <mike.kravetz@xxxxxxxxxx>
>> Acked-by: Yang Shi <shy828301@xxxxxxxxx>
>> ---
>> 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
