From: Johannes Weiner <hannes@cmpxchg.org>
To: Paul Bolle <pebolle@tiscali.nl>
Cc: Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/slab: use IS_ENABLED() instead of ZONE_DMA_FLAG
Date: Thu, 25 Sep 2014 14:50:47 -0400 [thread overview]
Message-ID: <20140925185047.GA21089@cmpxchg.org> (raw)
In-Reply-To: <1411667851.2020.6.camel@x41>
On Thu, Sep 25, 2014 at 07:57:31PM +0200, Paul Bolle wrote:
> The Kconfig symbol ZONE_DMA_FLAG probably predates the introduction of
> IS_ENABLED(). Remove it and replace its two uses with the equivalent
> IS_ENABLED(CONFIG_ZONE_DMA).
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> Build tested on x86_64 (on top of next-20140925).
>
> Run tested on i686 (on top of v3.17-rc6). That test required me to
> switch from SLUB (Fedora's default) to SLAB. That makes running this
> patch both more scary and less informative. Besides, I have no idea how
> to hit the codepaths I just changed. You'd expect this to not actually
> change slab.o, but I'm not sure how to check that. So, in short: review
> very much appreciated.
>
> mm/Kconfig | 5 -----
> mm/slab.c | 4 ++--
> 2 files changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 886db21..8e860c7 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -273,11 +273,6 @@ config ARCH_ENABLE_HUGEPAGE_MIGRATION
> config PHYS_ADDR_T_64BIT
> def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT
>
> -config ZONE_DMA_FLAG
> - int
> - default "0" if !ZONE_DMA
> - default "1"
> -
> config BOUNCE
> bool "Enable bounce buffers"
> default y
> diff --git a/mm/slab.c b/mm/slab.c
> index 628f2b5..766c90e 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -2243,7 +2243,7 @@ __kmem_cache_create (struct kmem_cache *cachep, unsigned long flags)
> cachep->freelist_size = freelist_size;
> cachep->flags = flags;
> cachep->allocflags = __GFP_COMP;
> - if (CONFIG_ZONE_DMA_FLAG && (flags & SLAB_CACHE_DMA))
> + if (IS_ENABLED(CONFIG_ZONE_DMA) && (flags & SLAB_CACHE_DMA))
> cachep->allocflags |= GFP_DMA;
GFP_DMA is actually safe to use even without CONFIG_ZONE_DMA, so you
only need to check for SLAB_CACHE_DMA here.
> @@ -2516,7 +2516,7 @@ static void cache_init_objs(struct kmem_cache *cachep,
>
> static void kmem_flagcheck(struct kmem_cache *cachep, gfp_t flags)
> {
> - if (CONFIG_ZONE_DMA_FLAG) {
> + if (IS_ENABLED(CONFIG_ZONE_DMA)) {
> if (flags & GFP_DMA)
> BUG_ON(!(cachep->allocflags & GFP_DMA));
> else
I think this assertion can be removed altogether and replaced by ORing
the passed in flags with the cache gfp flags. The page allocator will
catch any contradictions, but the 3 callsites that actually do use DMA
caches are well-behaved as of now.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: Paul Bolle <pebolle@tiscali.nl>
Cc: Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/slab: use IS_ENABLED() instead of ZONE_DMA_FLAG
Date: Thu, 25 Sep 2014 14:50:47 -0400 [thread overview]
Message-ID: <20140925185047.GA21089@cmpxchg.org> (raw)
In-Reply-To: <1411667851.2020.6.camel@x41>
On Thu, Sep 25, 2014 at 07:57:31PM +0200, Paul Bolle wrote:
> The Kconfig symbol ZONE_DMA_FLAG probably predates the introduction of
> IS_ENABLED(). Remove it and replace its two uses with the equivalent
> IS_ENABLED(CONFIG_ZONE_DMA).
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> Build tested on x86_64 (on top of next-20140925).
>
> Run tested on i686 (on top of v3.17-rc6). That test required me to
> switch from SLUB (Fedora's default) to SLAB. That makes running this
> patch both more scary and less informative. Besides, I have no idea how
> to hit the codepaths I just changed. You'd expect this to not actually
> change slab.o, but I'm not sure how to check that. So, in short: review
> very much appreciated.
>
> mm/Kconfig | 5 -----
> mm/slab.c | 4 ++--
> 2 files changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 886db21..8e860c7 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -273,11 +273,6 @@ config ARCH_ENABLE_HUGEPAGE_MIGRATION
> config PHYS_ADDR_T_64BIT
> def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT
>
> -config ZONE_DMA_FLAG
> - int
> - default "0" if !ZONE_DMA
> - default "1"
> -
> config BOUNCE
> bool "Enable bounce buffers"
> default y
> diff --git a/mm/slab.c b/mm/slab.c
> index 628f2b5..766c90e 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -2243,7 +2243,7 @@ __kmem_cache_create (struct kmem_cache *cachep, unsigned long flags)
> cachep->freelist_size = freelist_size;
> cachep->flags = flags;
> cachep->allocflags = __GFP_COMP;
> - if (CONFIG_ZONE_DMA_FLAG && (flags & SLAB_CACHE_DMA))
> + if (IS_ENABLED(CONFIG_ZONE_DMA) && (flags & SLAB_CACHE_DMA))
> cachep->allocflags |= GFP_DMA;
GFP_DMA is actually safe to use even without CONFIG_ZONE_DMA, so you
only need to check for SLAB_CACHE_DMA here.
> @@ -2516,7 +2516,7 @@ static void cache_init_objs(struct kmem_cache *cachep,
>
> static void kmem_flagcheck(struct kmem_cache *cachep, gfp_t flags)
> {
> - if (CONFIG_ZONE_DMA_FLAG) {
> + if (IS_ENABLED(CONFIG_ZONE_DMA)) {
> if (flags & GFP_DMA)
> BUG_ON(!(cachep->allocflags & GFP_DMA));
> else
I think this assertion can be removed altogether and replaced by ORing
the passed in flags with the cache gfp flags. The page allocator will
catch any contradictions, but the 3 callsites that actually do use DMA
caches are well-behaved as of now.
next prev parent reply other threads:[~2014-09-25 18:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-25 17:57 [PATCH] mm/slab: use IS_ENABLED() instead of ZONE_DMA_FLAG Paul Bolle
2014-09-25 17:57 ` Paul Bolle
2014-09-25 18:38 ` Christoph Lameter
2014-09-25 18:38 ` Christoph Lameter
2014-09-25 18:50 ` Johannes Weiner [this message]
2014-09-25 18:50 ` Johannes Weiner
2014-09-27 9:56 ` Paul Bolle
2014-09-27 9:56 ` Paul Bolle
2014-09-27 15:53 ` Christoph Lameter
2014-09-27 15:53 ` Christoph Lameter
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=20140925185047.GA21089@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pebolle@tiscali.nl \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.