在 2025/1/28 7:04, Andrew Morton 写道:
On Fri, 24 Jan 2025 19:21:27 +0800 yangge1116@xxxxxxx wrote:From: yangge <yangge1116@xxxxxxx> Commit 60a60e32cf91 ("Revert "mm/cma.c: remove redundant cma_mutex lock"") simply reverts to the original method of using the cma_mutex to ensure that alloc_contig_range() runs sequentially. This change was made to avoid concurrency allocation failures. However, it can negatively impact performance when concurrent allocation of CMA memory is required. To address this issue, we could introduce an API for concurrency settings, allowing users to decide whether their CMA can perform concurrent memory allocations or not.The term "users" tends to refer to userspace code. Here I'm thinking you mean in-kernel code, so a better term to use is "callers".
Ok, thank you. I will change it in the next version.
This new interface has no callers. We prefer not to merge unused code! Please send along the patch which calls cma_set_concurrency() so we can better understand this proposal and so that the new code is testable.
Ok, thank you. I will add the caller in the next version. In fact the patch has cc:stable, which makes things
stranger. Why should the -stable maintainers merge a patch which doesn't do anything? And please quantify the benefit. "negatively impact" is too vague. How much benefit can we expect our users to see from this? Some runtime testing results would be good. And please describe in more detail why this particular caller doesn't require concurrency protection. And help other developers understand when it is safe for them to use concurr_alloc==false.
Ok, thank you.
