On Wed, Oct 21, 2020 at 05:15:53PM -0700, Mike Kravetz wrote: > 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. Hi Mike, > > 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? I actually have suggested it few months ago, but the idea was opposed by Joonsoo: https://lkml.org/lkml/2020/4/3/12 . The time of a bitmap operation is definitely not an issue in my context, but I can't speak for something like an embedded/rt case. Thanks!
