linux-kernel - Re: [PATCH] mm/cma: add an API to enable/disable concurrent memory allocation for the CMA

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <44348250-64f2-4420-a786-d42c3ad923b0@126.com>
Date: Sat, 8 Feb 2025 16:19:24 +0800
From: Ge Yang <yangge1116@....com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org, stable@...r.kernel.org,
 21cnbao@...il.com, david@...hat.com, baolin.wang@...ux.alibaba.com,
 aisheng.dong@....com, liuzixing@...on.cn
Subject: Re: [PATCH] mm/cma: add an API to enable/disable concurrent memory
 allocation for the CMA



在 2025/1/28 7:04, Andrew Morton 写道:
> On Fri, 24 Jan 2025 19:21:27 +0800 yangge1116@....com wrote:
> 
>> From: yangge <yangge1116@....com>
>>
>> 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.