Re: [PATCH] mm/cma: Remove CONFIG_CMA_SYSFS option

[Jean Delvare <jdelvare@suse.de>]

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 <jdelvare@suse.de> 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 <jdelvare@suse.de>
> > ---
> > 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).

-- 
Jean Delvare
SUSE L3 Support