From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B85A033890D for ; Fri, 14 Nov 2025 15:48:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763135287; cv=none; b=bn+UuWNZNhCJTR5GCQT5UP6Y4B8O6e4Ra70lp+bpfquC9OYGlzTifD8szOl+5R/en6h8Ts6L3Cnvh5VJ8yg6sxKoP40qF07RqLWKl6zF2qRNit8jDY19Ot5W/f4LeVDwenR84ifP/VPJaU4irg6M/0/U0vuX4bxP35GCwWVAhmA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763135287; c=relaxed/simple; bh=vfbrct6bJzrCc+Mkh/vkmrp/+VzAY67l9cyJGnmW9xQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EU0LGfm2v2clHTmYI32G2gJ6izn16gH/kM31KVXzy0UyN+PTjc7ROKpy/LLbPDvyTOWQVexJTL24oMBwVcXa04hpqkWXdl8qrVUkBfp/BCvjfBR4xawQzO+fEhpCHII007azmo4qfAgr3qMGE3aU+k4r83sJBrEBodELbNKD0Xw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VxcWREvS; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VxcWREvS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F007C4CEF1; Fri, 14 Nov 2025 15:48:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763135287; bh=vfbrct6bJzrCc+Mkh/vkmrp/+VzAY67l9cyJGnmW9xQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VxcWREvSw7ifZWkM1yvTpCn19i/Y5OvbOMdF5dRd1xm4xWjctyA0qlMhfljwgDa0D sGBwq6mnnONS1MdJN/12wMATKfVe26UcSEz9MZ15Kek3n4N9ckGuJtzRiXxnJQJ1iv tIUATjxQP7CcPG5kHwSWbTrZYGzX/PiuULTrcOZhn1N09OUYY9K0fPz+IN8cOkeJfE mPZxAQVgSNF3kjFKiQ7BsiEXnWIWfMcJKUukhFgfJpP26TngN5wa4xyGFwGDwSQqtp YyerKFmxatyqlPXRB71bEldfydWnM05KF3SO8cgbZExX1Stn7bJAsMooKGTtGc6LHu q2uuxNMhk7S2w== From: SeongJae Park To: Jean Delvare Cc: SeongJae Park , linux-mm@kvack.org, LKML , David Hildenbrand Subject: Re: [PATCH] mm/cma: Remove CONFIG_CMA_SYSFS option Date: Fri, 14 Nov 2025 07:47:57 -0800 Message-ID: <20251114154759.76541-1-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20251114094814.3b2efb09@endymion> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Fri, 14 Nov 2025 09:48:14 +0100 Jean Delvare wrote: > Hi Seong Jae, > > On Thu, 13 Nov 2025 17:09:27 -0800, SeongJae Park wrote: > > On Thu, 13 Nov 2025 14:56:36 +0100 Jean Delvare wrote: > > > > > The sysfs interface to CMA has a marginal runtime cost and a small > > > footprint, there's no reason not to include it in all kernels where > > > the dependencies are satisfied. > > > > Overall change looks good to me. I have a question below, though. > > > > > > > > Signed-off-by: Jean Delvare > > > --- > > > As discussed with David: > > > https://lkml.org/lkml/2025/8/6/371 > > > > > > arch/loongarch/configs/loongson3_defconfig | 1 - > > > arch/s390/configs/debug_defconfig | 1 - > > > arch/s390/configs/defconfig | 1 - > > > mm/Kconfig | 7 ------- > > > mm/Makefile | 4 +++- > > > mm/cma.h | 4 ++-- > > > 6 files changed, 5 insertions(+), 13 deletions(-) > > > > > > --- linux-6.17.orig/arch/loongarch/configs/loongson3_defconfig > > > +++ linux-6.17/arch/loongarch/configs/loongson3_defconfig > > [...] > > > --- linux-6.17.orig/mm/cma.h > > > +++ linux-6.17/mm/cma.h > > > @@ -49,7 +49,7 @@ struct cma { > > > char name[CMA_MAX_NAME]; > > > int nranges; > > > struct cma_memrange ranges[CMA_MAX_RANGES]; > > > -#ifdef CONFIG_CMA_SYSFS > > > +#ifdef CONFIG_SYSFS > > > /* the number of CMA page successful allocations */ > > > atomic64_t nr_pages_succeeded; > > > /* the number of CMA page allocation failures */ > > > @@ -80,7 +80,7 @@ static inline unsigned long cma_bitmap_m > > > return cmr->count >> cma->order_per_bit; > > > } > > > > > > -#ifdef CONFIG_CMA_SYSFS > > > +#ifdef CONFIG_SYSFS > > > void cma_sysfs_account_success_pages(struct cma *cma, unsigned long nr_pages); > > > void cma_sysfs_account_fail_pages(struct cma *cma, unsigned long nr_pages); > > > void cma_sysfs_account_release_pages(struct cma *cma, unsigned long nr_pages); > > > > Why don't you check CONFIG_CMA together? I think that makes the change more > > complete and safe. > > > > I found there is no file that can be compiled without CONFIG_CMA but still > > including this header file, so I expect no real issue for now, though. > > This would actually make no difference. This header file is internal > and not expected to be included by any file besides that CMA core > itself, so it is assumed that CONFIG_CMA=y whenever this header file > is used. If not, then things would break already, even without my > proposed changes (due to cma_areas and cma_area_count being declared > but never defined). Makes sense. Reviewed-by: SeongJae Park Thanks, SJ [...]