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".
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. 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.
