On Fri, Mar 19, 2021 at 03:42:08PM -0700, Mike Kravetz wrote:

The locks acquired in free_huge_page are irq safe.  However, in certain
circumstances the routine update_and_free_page could sleep.  Since
free_huge_page can be called from any context, it can not sleep.

Use a waitqueue to defer freeing of pages if the operation may sleep.  A
new routine update_and_free_page_no_sleep provides this functionality
and is only called from free_huge_page.

Note that any 'pages' sent to the workqueue for deferred freeing have
already been removed from the hugetlb subsystem.  What is actually
deferred is returning those base pages to the low level allocator.

So maybe I'm stupid, but why do you need that work in hugetlb? Afaict it
should be in cma_release().

Also, afaict cma_release() does free_contig_range() *first*, and then
does the 'difficult' bits. So how about you re-order
free_gigantic_page() a bit to make it unconditionally do
free_contig_range() and *then* call into CMA, which can then do a
workqueue thingy if it feels like it.

That way none of the hugetlb accounting is delayed, and only CMA gets to
suffer.