On 2020/10/17 6:52, 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. Roman Gushchin (2): mm: cma: make cma_release() non-blocking mm: hugetlb: don't drop hugetlb_lock around cma_release() call mm/cma.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++-- mm/hugetlb.c | 6 ------ 2 files changed, 49 insertions(+), 8 deletions(-)
I don't think this patch is a good idea.It transfers part or even all of the time of cma_release to cma_alloc, which is more concerned by performance indicators. On Android phones, CPU resource competition is intense in many scenarios, As a result, kernel threads and workers can be scheduled only after some ticks or more. In this case, the performance of cma_alloc will deteriorate significantly, which is not good news for many services on Android.
