On 10/16/20 3:52 PM, Roman Gushchin wrote: > This small patchset makes cma_release() non-blocking and simplifies > the code in hugetlbfs, where previously we had to temporarily drop > hugetlb_lock around the cma_release() call. > > It should help Zi Yan on his work on 1 GB THPs: splitting a gigantic > THP under a memory pressure requires a cma_release() call. If it's > a blocking function, it complicates the already complicated code. > Because there are at least two use cases like this (hugetlbfs is > another example), I believe it's just better to make cma_release() > non-blocking. > > It also makes it more consistent with other memory releasing functions > in the kernel: most of them are non-blocking.
Thanks for looking into this Roman. I may be missing something, but why does cma_release have to be blocking today? Certainly, it takes the bitmap in cma_clear_bitmap and could block. However, I do not see why cma->lock has to be a mutex. I may be missing something, but I do not see any code protected by the mutex doing anything that could sleep? Could we simply change that mutex to a spinlock? -- Mike Kravetz
