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 89923C0218A for ; Tue, 28 Jan 2025 09:58:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 170A32801EF; Tue, 28 Jan 2025 04:58:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0D25F2801E3; Tue, 28 Jan 2025 04:58:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E8E092801EF; Tue, 28 Jan 2025 04:58:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id C57F62801E3 for ; Tue, 28 Jan 2025 04:58:46 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 7261BC0FCF for ; Tue, 28 Jan 2025 09:58:46 +0000 (UTC) X-FDA: 83056411452.16.1B3C847 Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) by imf15.hostedemail.com (Postfix) with ESMTP id 8D551A000F for ; Tue, 28 Jan 2025 09:58:44 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RQekWiDn; spf=pass (imf15.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.54 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738058324; 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=SSKspFr92rhO19guamMZKYUUwmiEHnEHWbR04twXjdY=; b=JDEwabgUKKBAEh+EtvSd3zihsu0Bw7JUaiZ0bSH3rnVkJO5Pms+cBhMGZapEySUqCHbZNX Nurl8/rP8qJz2DOy7lgrmHzuAOTMzdlhQpA66GIim7Obf8hVg0SojZ2uU9yuSGOb4pFaV4 e18WXa/AHx99iJpvBW7bTxzDUIlmLZY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738058324; a=rsa-sha256; cv=none; b=LM/XxhgnlIotyUhQDwH2skPrghTnCT4P+2PiFsFW26S1T0ZApz4UafofkE5Q1lHPl1W1eN hGhJLfYlAzULaSIZ/31GuBWOUdqUuVgo3vy90ZcFfKtHkqM1fS+kvdCkd5zmV1Tox4fIFg q9waun3eDCpoNrJZGVhlDBxNj/UqujA= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RQekWiDn; spf=pass (imf15.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.54 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-vs1-f54.google.com with SMTP id ada2fe7eead31-4b10dd44c8bso1605173137.3 for ; Tue, 28 Jan 2025 01:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738058323; x=1738663123; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=SSKspFr92rhO19guamMZKYUUwmiEHnEHWbR04twXjdY=; b=RQekWiDn3uprh8V/UOkRIlOjdYsWap6JJW+vHGw0UCbsEctGWLDMAevVC3VWHhu8Yn /tV6/FXqLgX/zbJmcuTk01sU2vPdMpIWqNRUpBugqHSytQ9jUVcGZUxiNNT4TAg+eFir lH3HaeHeerlZnwVsLirYUayc2bNjPVQTZhPK401PIMxV5ptu9524HbrCHAOMjzHA3XbD a8JMIz9YU3uB1ZjyLkHjKQKebzM6AGeqcgZoL06qymkHAqjsTp6syUv70bXqAb1vfllW O6SE6OuJqxmFtj94CIq3fPONS2jjdhFI8PgW+ADNb+l4JXWDVrOpCVXHrcrlAVhQxRCu 9Neg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738058323; x=1738663123; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SSKspFr92rhO19guamMZKYUUwmiEHnEHWbR04twXjdY=; b=DHTj7GBWDGrA3ZuXvHq9MHveyBhyoPKojeixqXctn5MXH1NmG3Tma4Xgz7XwAFt1cJ DczCqOs9ei80sjPl/tIvnHgdCr/1PX29oPceCd8hsqRRZMYxV9u0r7WnvzEtlR/RBZP3 1ePcQrq1tSl/iN4xeKOAXxRLBLDgZ6E8ppMUVdsD5rqlk6ly4eJVRUg5UwWyy/LTc1ez F17bKyrYbvYMXrkG8M9Qc0bx/laVaSBk5kSIDzfAvffivU8iXEbCuDPQoo47U4dyDsBw 5p75rX1SyFKGSE0O+zK4GZ49hfdU7iB+It5RdvTq9r3YhoG1101h0Z5lfuTsJH6Avy3l sopQ== X-Forwarded-Encrypted: i=1; AJvYcCUeWyEoVxkuvz7hMZqReQ78Nhr2i3sRnMpSbuCsR8mSGltriBy3Ub43g9H1mzD5OeqZRNGdzBkUcA==@kvack.org X-Gm-Message-State: AOJu0Yw+h9xxwhymiAOKKB2l19LhlAzVjuOJW37CWzK50A9LeTz1IuIB XUtC7/PtT+hb3MJYuoq8gkRGa4svEbkPXWg1fTJsaa2ay7Uatto1V1klQ3nlsSyQWuEwZKvYbZI ha36SpttYhunyAg8UngT1X3zVbaA= X-Gm-Gg: ASbGnctaGNkFzThUuvza/DBxNZXCXpC0KJp2qeJVlBIBM5mxb8R7fN9Af/sHpN4KwUU ozCs1j743mJ2sUXwGuN2dT4MEBNaliEP4HspyHV81tUGuEWPvL2pw4Yuj1bPrnYr6omAIcnVRGE X8eUwAg2t5a/SBTEq0kNALSoPWR5qQ4Zo= X-Google-Smtp-Source: AGHT+IEjvwgB90H/GRLtszWh+qAo95uV5i1wiKXOCfuNgEF3LWvZho13BarZ4v2hnf1Ok1W/0IvWOwKgABnjAO2XKVQ= X-Received: by 2002:a05:6102:a53:b0:4b2:5c4b:55e7 with SMTP id ada2fe7eead31-4b690cde3a2mr35483312137.25.1738058323633; Tue, 28 Jan 2025 01:58:43 -0800 (PST) MIME-Version: 1.0 References: <1737717687-16744-1-git-send-email-yangge1116@126.com> In-Reply-To: <1737717687-16744-1-git-send-email-yangge1116@126.com> From: Barry Song <21cnbao@gmail.com> Date: Tue, 28 Jan 2025 22:58:32 +1300 X-Gm-Features: AWEUYZmh8QdF0cjEckRpQuu80pJvsy9bKgNFBHsx6WZM5gmpzBjs_t6EnDkaR4A Message-ID: Subject: Re: [PATCH] mm/cma: add an API to enable/disable concurrent memory allocation for the CMA To: yangge1116@126.com Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, david@redhat.com, baolin.wang@linux.alibaba.com, aisheng.dong@nxp.com, liuzixing@hygon.cn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: f7tgun443az74q7qezk4ghoo7wyjqdz1 X-Rspamd-Queue-Id: 8D551A000F X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1738058324-803981 X-HE-Meta: U2FsdGVkX18H+gFAG5A8ax6ooAFkfX/Qr3msHV4UieBzwfTZi2OAtRdaBLNj6qBgG0yx9WdNlfruY3XahxCfiyVEMyfv20ScDf0xKFSow1uSuWWagr/+7o6W5HTx62cKSMj8e8OqhHAvzm9GMJ/vr1NcezmqHCgH0S7Ag+vhAIMFHUDg2eWw7nbUtXOg8+ueARK8VARQV7L3Rw/ZaP1pjPDVQodavX9qxsnJGPlMEbyQE3bFyOJ5p5nwg6vV7aFPN1yCaE0TpHDf489S+hniOSRN/jwtUAtawtkcWFoxEUZ4EhiSea0RjUAU7itLEd+2rA27eRvt+NnuUiJpswKoOp2Xk5MPT3f8QJJOhl5+aYqbSQ8PqaYrdFwvclOIoUeMIYCMn9hAYYgn1h6Wwen7fDmLpMAHH99hlRcqIdgnf6B04V07d3LL0aF8CvCWzNcSV+ilw9s8bwqg/7pz5aRhWnMXtatJq6D9lBo+z/r6j984qzyV80zCLFcTsnLQAk+jj3UMLa3MwoKSzuZNHKJgx0QVySCd2fhbpI1lmA6hPYCjAj7uWcSNaFRLuETO85W2IsqXkbP88G7TCM+FN6fxWAIekQCAFNoqfQ6WHq2RmPmeXtPWzqjoBZX937SrWL0K7KrXwCSkV9YGWSEYs/33wIF4C13PbImboLjBwF1l2BOUb0b9Sv1oLokyWJAX0YZ4GV6hvV77sPWQ7AM2HcO9NN4MriJG5MrSF5Rk3J5ng4zG0zF3yM39KtNVMSEFem35XNoeWI1tzwSf3Oss2/iBXYH5g+e/XRPbKiiFCrmjMF+B5Lv+Zw9FDk+18gg5X8qF7fsRaZrNwxJWaqzSCY6oH4W4WtSkxXBeCe0kdUbnQeVR/xUjap+PqYcX/LmMWJZkHwp4CIKyGUASlSlJ0W6Z2J7qJvtuQyVNhIYmdgMShl+DcQb3Eme+T2yAKn0BQp9hGYba1bIFlzZcwYQoa0e 6aet+irV DfcGciK/41jNmRNb/XtBe3uPFK41iThPUlN8AUjvj9R7b5IMbRBRX4MrW/TK0WzyYV3prULMzNMgaYPdrCnQFdTNUNTZJwxJznAX/Dy35DfD91QqOnSBJS8jMJPQ4YaZR3mkSZU0gtGy06QJeeooOJwmFwrSB4dCIwWBByktJwQxEjUHLgpGoRH4WVK/5Bvvoiv0mtKTuU7ZH4Swp8BWeZQ/4EJYr/Jx9RZ2q/yVC4G5tYb0QdbNrUQUDTguJyqLRaFp8AdINm8dILk5CPTDfXoJZCIJl5kW/GbJ6h5GxvYie+35QZcSSPNKL6mERwGfMBNc2VP6NCvMX2eTdE2XhkDRFKR2bkRAz22QR5S4pIQieGY9oyD/sPLcvXPDLl+tVLThpFoXsd4w+Y6wacJGM9V2PUg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000136, 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 Sat, Jan 25, 2025 at 12:21=E2=80=AFAM 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 avoi= d > concurrency allocation failures. However, it can negatively impact > performance when concurrent allocation of CMA memory is required. Do we have some data? > > 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. Who is the intended user of cma_set_concurrency? I also feel it is somewhat unsafe since cma->concurr_alloc is not protected by any locks. Will a user setting cma->concurr_alloc =3D 1 encounter the original issue t= hat commit 60a60e32cf91 was attempting to fix? > > Fixes: 60a60e32cf91 ("Revert "mm/cma.c: remove redundant cma_mutex lock""= ) > Signed-off-by: yangge > Cc: > --- > include/linux/cma.h | 2 ++ > mm/cma.c | 22 ++++++++++++++++++++-- > mm/cma.h | 1 + > 3 files changed, 23 insertions(+), 2 deletions(-) > > diff --git a/include/linux/cma.h b/include/linux/cma.h > index d15b64f..2384624 100644 > --- a/include/linux/cma.h > +++ b/include/linux/cma.h > @@ -53,6 +53,8 @@ extern int cma_for_each_area(int (*it)(struct cma *cma,= void *data), void *data) > > extern void cma_reserve_pages_on_error(struct cma *cma); > > +extern bool cma_set_concurrency(struct cma *cma, bool concurrency); > + > #ifdef CONFIG_CMA > struct folio *cma_alloc_folio(struct cma *cma, int order, gfp_t gfp); > bool cma_free_folio(struct cma *cma, const struct folio *folio); > diff --git a/mm/cma.c b/mm/cma.c > index de5bc0c..49a7186 100644 > --- a/mm/cma.c > +++ b/mm/cma.c > @@ -460,9 +460,17 @@ static struct page *__cma_alloc(struct cma *cma, uns= igned long count, > spin_unlock_irq(&cma->lock); > > pfn =3D cma->base_pfn + (bitmap_no << cma->order_per_bit)= ; > - mutex_lock(&cma_mutex); > + > + /* > + * If the user sets the concurr_alloc of CMA to true, con= current > + * memory allocation is allowed. If the user sets it to f= alse or > + * does not set it, concurrent memory allocation is not a= llowed. > + */ > + if (!cma->concurr_alloc) > + mutex_lock(&cma_mutex); > ret =3D alloc_contig_range(pfn, pfn + count, MIGRATE_CMA,= gfp); > - mutex_unlock(&cma_mutex); > + if (!cma->concurr_alloc) > + mutex_unlock(&cma_mutex); > if (ret =3D=3D 0) { > page =3D pfn_to_page(pfn); > break; > @@ -610,3 +618,13 @@ int cma_for_each_area(int (*it)(struct cma *cma, voi= d *data), void *data) > > return 0; > } > + > +bool cma_set_concurrency(struct cma *cma, bool concurrency) > +{ > + if (!cma) > + return false; > + > + cma->concurr_alloc =3D concurrency; > + > + return true; > +} > diff --git a/mm/cma.h b/mm/cma.h > index 8485ef8..30f489d 100644 > --- a/mm/cma.h > +++ b/mm/cma.h > @@ -16,6 +16,7 @@ struct cma { > unsigned long *bitmap; > unsigned int order_per_bit; /* Order of pages represented by one = bit */ > spinlock_t lock; > + bool concurr_alloc; > #ifdef CONFIG_CMA_DEBUGFS > struct hlist_head mem_head; > spinlock_t mem_head_lock; > -- > 2.7.4 > > Thanks Barry