On 3/24/21 1:43 AM, Michal Hocko wrote:

On Tue 23-03-21 11:51:04, Mike Kravetz wrote:

quoted

On 3/22/21 11:10 AM, Roman Gushchin wrote:

quoted

On Mon, Mar 22, 2021 at 10:42:23AM -0700, Mike Kravetz wrote:

quoted

Cc: Roman, Christoph

On 3/22/21 1:41 AM, Peter Zijlstra wrote:

quoted

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

quoted

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().

My thinking (which could be totally wrong) is that cma_release makes no
claims about calling context.  From the code, it is pretty clear that it
can only be called from task context with no locks held.  Although,
there could be code incorrectly calling it today hugetlb does.  Since
hugetlb is the only code with this new requirement, it should do the
work.

Wait!!!  That made me remember something.
Roman had code to create a non-blocking version of cma_release().
https://lore.kernel.org/linux-mm/20201022225308.2927890-1-guro@fb.com/ (local)

There were no objections, and Christoph even thought there may be
problems with callers of dma_free_contiguous.

Perhaps, we should just move forward with Roman's patches to create
cma_release_nowait() and avoid this workqueue stuff?

Sounds good to me. If it's the preferred path, I can rebase and resend
those patches (they been carried for some time by Zi Yan for his 1GB THP work,
but they are completely independent).

Thanks Roman,

Yes, this is the preferred path.  If there is a non blocking version of
cma_release, then it makes fixup of hugetlb put_page path much easier.

I do not object to the plan I just want to point out that the sparse
vmemmap for hugetlb pages will need to recognize sleep/nosleep variants
of the freeing path as well to handle its vmemmap repopulate games.

Yes,

I also commented elsewhere that we will likely want to do the
drop/reacquire lock for each page in the looping page free routines when
adding the vmemmap freeing support.

Unless someone thinks otherwise, I still think it is better to first fix
the hugetlb put_page/free_huge_page path with this series.  Then move on
to the free vmemmap series.
-- 
Mike Kravetz