From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28F09C02188 for ; Mon, 27 Jan 2025 23:04:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4ED5C2801BB; Mon, 27 Jan 2025 18:04:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 47634280163; Mon, 27 Jan 2025 18:04:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 318302801BB; Mon, 27 Jan 2025 18:04:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 3490B280163 for ; Mon, 27 Jan 2025 18:04:17 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 957FD1A0815 for ; Mon, 27 Jan 2025 23:04:16 +0000 (UTC) X-FDA: 83054762112.11.033F941 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf19.hostedemail.com (Postfix) with ESMTP id E5DD81A0007 for ; Mon, 27 Jan 2025 23:04:14 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=XsWAPrX1; spf=pass (imf19.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738019055; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=VcJ7QVUfZqGP+JdU2xOQrP4KjxmsK/blFuJdmuuRwLE=; b=oJzSqt1GvXFcVvTtU00ChQgdvYPgxWHUBiazmnzQ45iX0DPD1TdbHMqtrqVxlZOXRsHbUW l6LxGO439QkoWMW/fy9YCiyPYlJhmCb65SjpKYbtSb7ZCFXZXlNqar2KbRycMHg9qFrHlo QWy6DT3t1OyZDdmGglkiMH6IYsFzrfA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738019055; a=rsa-sha256; cv=none; b=ZWfTCzoGVuRMrOWwfttO33KS/EfcRez601JInqK3A16FjCXhNM/VFRN4STiJ2EkJe8/h8d JpH3z1WiAAJ+XMrA5txcQKnECZtT/+Ad7RcEkoU5M/r6nVa7sC2cAuFUfNe3de3Cxnzy0C QmvJfH6KcmZ9SGZwgdAEBTn7A4MHKcU= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=XsWAPrX1; spf=pass (imf19.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 49B55A41C22; Mon, 27 Jan 2025 23:02:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A0E4DC4CED2; Mon, 27 Jan 2025 23:04:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1738019053; bh=uVNDsHFhS/Z00h0YDHX4jxsFOnQKIB4Pp4MJrTUG3Sg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XsWAPrX1FWdMbgD1IubkRCk8QPqD5wz4ZD8jSAba0MtfCu+qysJOiW0upd7bTIyCb Ght8zfo4wSt30oSO/HU16rKifbratUA0zlY3j5cFmhropouw5Piw2V2ep9WowROhvg SqXKr3t6eQZ1zttDFYcPRZJ4O/tLT+CrtTX4ClNs= Date: Mon, 27 Jan 2025 15:04:12 -0800 From: Andrew Morton To: yangge1116@126.com Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, 21cnbao@gmail.com, david@redhat.com, baolin.wang@linux.alibaba.com, aisheng.dong@nxp.com, liuzixing@hygon.cn Subject: Re: [PATCH] mm/cma: add an API to enable/disable concurrent memory allocation for the CMA Message-Id: <20250127150412.875e666a728c3d7bde0726b0@linux-foundation.org> In-Reply-To: <1737717687-16744-1-git-send-email-yangge1116@126.com> References: <1737717687-16744-1-git-send-email-yangge1116@126.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: 4xro1yazo65t4kegw5axck6zi8for8r1 X-Rspam-User: X-Rspamd-Queue-Id: E5DD81A0007 X-Rspamd-Server: rspam03 X-HE-Tag: 1738019054-626499 X-HE-Meta: U2FsdGVkX18TtFkmxFT2IoMxQeFgNRH4n0Ct6H/58e/v+9NUM+W/kvP2QjfNIFUDqbaQZhYGPZkh7KxeJZdeJ0LQlXO/Nv3U4xieXzDc+TlhXVao0wqwg7xYmLghB1/tc4MJiYYp8DQ/t6VnmF775dem5Q8b/uCfpY3JVwo2YnUzS57S4gFi0bpLIfxJHo4IMtFRFXbn2kDVetMbDbO/gbzJ1JkHZtOgi1yhIpiQCyxG8DphKUbXr0hCrTw8aFnErPQ+/p6WFfcBDsv9nJHASiClk6uNmoMVqDDPtjQt8L77vmrFFz7QX/by05CquNuniB1CTCevordVrjqB3bC9PUu4/RjFy7RE5y7gmuS+Dd95blzlQJpnrw7YJB6O2xIAFKxa/51ewWS8eJeBBqUabh41P2oO4U6nt95E6BSDz9AV5zmjVAt5mHNUvux3VBIpirVUIS8dA9gUKedB36z6YIXfRUiHsh3IBwt6rSxXkPzB0Euh7oye6fP0ysFRFivBvUBZ4iJwp/Eq970Rnk9xPmy+GRFRnUD6ciOHtjLPe6rKHuL41zF9jTKEbWTJabMtUOJD9YuQ6KjaCRyQsWT2uyHYZnbdcrVCuG6vrfdex7VWe+ZMRA0OPYTmy15YwMPLmT3jRn6uRM64xpUuWV2aP4CDwNw9rXNs9RN3TjRDoXrsyBz7eHHCOWp6T7OmvW2zo2nz9r1qGt5+7QQ9rhDoVtTRw7A/8Yy98vw4BLAiKpEPSDQ6Fir/wP4mAsYxfCJftmG4nxa4WHyIBCokQ9hbLiOicPSPw2mOR/7K0jit+Bi8xRNZ6Q0CEwboPIi8gYEKHyxkm7lE8Neh94x5iEo8lOsZ43XHrZtx2u8UVgHLnjP7r7D609NVM/4Zz+T9UvHtjLVJ0kru/xlcnDcdqgaWzP52n53vENg56ZTzJkV3PM9IVQSTqssqvFRRsiYHr9nJW34JANBz4/yK+AlISzV EjekDhq9 mmcIculUjAvy/4BhuOJdM+7WoVegKixNl+u7yvMEx7AW6v2GKvqo1F1vlKVibrgFrzJ6wnZFqiBVmoNO6ZAgEZM/fId3b5MxkVZkq6qwicb8vExRDN2gHgZMmIu8qu/wKUbKb2cVKhIw+SOg/egC5GCCrcUvMw6qhC7QOj34jWkMT2Ku+0X+7hedZUa+gDGC0CaXFiUOOGfV7DPMmTTrMGzj8izxRryXgH0/qkTfBGTaSmn1UYeMERJTQcPgATULiba4vASkqpayRu7L3ol5QKfx8bv42fvUOwWs32h2B6PkNUIzSTZOVaCjVpA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, 24 Jan 2025 19:21:27 +0800 yangge1116@126.com wrote: > From: yangge > > 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.