On 18.02.25 13:19, Ge Yang wrote:
在 2025/2/18 19:45, David Hildenbrand 写道:
On 18.02.25 12:40, yangge1116@126.com wrote:
From: Ge Yang yangge1116@126.com
Since the introduction of commit c77c0a8ac4c52 ("mm/hugetlb: defer freeing of huge pages if in non-task context"), which supports deferring the freeing of hugetlb pages, the allocation of contiguous memory through cma_alloc() may fail probabilistically.
In the CMA allocation process, if it is found that the CMA area is occupied by in-use hugetlb folios, these in-use hugetlb folios need to be migrated to another location. When there are no available hugetlb folios in the free hugetlb pool during the migration of in-use hugetlb folios, new folios are allocated from the buddy system. A temporary state is set on the newly allocated folio. Upon completion of the hugetlb folio migration, the temporary state is transferred from the new folios to the old folios. Normally, when the old folios with the temporary state are freed, it is directly released back to the buddy system. However, due to the deferred freeing of hugetlb pages, the PageBuddy() check fails, ultimately leading to the failure of cma_alloc().
Here is a simplified call trace illustrating the process: cma_alloc() ->__alloc_contig_migrate_range() // Migrate in-use hugetlb folios ->unmap_and_move_huge_page() ->folio_putback_hugetlb() // Free old folios ->test_pages_isolated() ->__test_page_isolated_in_pageblock() ->PageBuddy(page) // Check if the page is in buddy
To resolve this issue, we have implemented a function named wait_for_freed_hugetlb_folios(). This function ensures that the hugetlb folios are properly released back to the buddy system after their migration is completed. By invoking wait_for_freed_hugetlb_folios() before calling PageBuddy(), we ensure that PageBuddy() will succeed.
Fixes: c77c0a8ac4c52 ("mm/hugetlb: defer freeing of huge pages if in non-task context") Signed-off-by: Ge Yang yangge1116@126.com Cc: stable@vger.kernel.org
Acked-by: David Hildenbrand david@redhat.com
+void wait_for_freed_hugetlb_folios(void) +{ + flush_work(&free_hpage_work);
BTW, I was wondering if we could optimize out some calls here by sensing if there is actually work.
for_each_hstate(h) { if (hugetlb_vmemmap_optimizable(h)) { flush_work(&free_hpage_work); break;> } } Is this adjustment okay?
I think that's better, except that it would still trigger in scenarios where hugetlb is completely unused if CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP is around.
Can't we check hpage_freelist?
if (llist_empty(&hpage_freelist)) return; flush_work(&free_hpage_work);
It should be able to deal with races (we don't care if something is getting added concurrently, only if there is something right now).