linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: Jean Delvare <jdelvare@suse.de>
Cc: SeongJae Park <sj@kernel.org>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
	David Hildenbrand <david@redhat.com>
Subject: Re: [PATCH] mm/cma: Remove CONFIG_CMA_SYSFS option
Date: Fri, 14 Nov 2025 07:47:57 -0800	[thread overview]
Message-ID: <20251114154759.76541-1-sj@kernel.org> (raw)
In-Reply-To: <20251114094814.3b2efb09@endymion>

On Fri, 14 Nov 2025 09:48:14 +0100 Jean Delvare <jdelvare@suse.de> 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 <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).

Makes sense.

Reviewed-by: SeongJae Park <sj@kernel.org>


Thanks,
SJ

[...]


  reply	other threads:[~2025-11-14 15:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-13 13:56 [PATCH] mm/cma: Remove CONFIG_CMA_SYSFS option Jean Delvare
2025-11-13 15:35 ` David Hildenbrand (Red Hat)
2025-11-13 16:57   ` Jean Delvare
2025-11-14  1:09 ` SeongJae Park
2025-11-14  8:48   ` Jean Delvare
2025-11-14 15:47     ` SeongJae Park [this message]
2025-11-14  8:34 ` Oscar Salvador

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251114154759.76541-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=david@redhat.com \
    --cc=jdelvare@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).