Cc: Roman, Christoph On 3/22/21 1:41 AM, Peter Zijlstra wrote: > 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().
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-g...@fb.com/ 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? -- Mike Kravetz
