[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20160328141911.3048ab8d406b86a6e5b9f910@linux-foundation.org>
Date: Mon, 28 Mar 2016 14:19:11 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: js1304@...il.com
Cc: Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Jesper Dangaard Brouer <brouer@...hat.com>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Joonsoo Kim <iamjoonsoo.kim@....com>
Subject: Re: [PATCH 02/11] mm/slab: remove BAD_ALIEN_MAGIC again
On Mon, 28 Mar 2016 14:26:52 +0900 js1304@...il.com wrote:
> From: Joonsoo Kim <iamjoonsoo.kim@....com>
>
> Initial attemp to remove BAD_ALIEN_MAGIC is once reverted by
> 'commit edcad2509550 ("Revert "slab: remove BAD_ALIEN_MAGIC"")'
> because it causes a problem on m68k which has many node
> but !CONFIG_NUMA.
Whaaa? How is that even possible? I'd have thought that everything
would break at compile time (at least) with such a setup.
> In this case, although alien cache isn't used
> at all but to cope with some initialization path, garbage value
> is used and that is BAD_ALIEN_MAGIC. Now, this patch set
> use_alien_caches to 0 when !CONFIG_NUMA, there is no initialization
> path problem so we don't need BAD_ALIEN_MAGIC at all. So remove it.
>
> ...
>
> @@ -1205,7 +1203,7 @@ void __init kmem_cache_init(void)
> sizeof(struct rcu_head));
> kmem_cache = &kmem_cache_boot;
>
> - if (num_possible_nodes() == 1)
> + if (!IS_ENABLED(CONFIG_NUMA) || num_possible_nodes() == 1)
> use_alien_caches = 0;
>
> for (i = 0; i < NUM_INIT_LISTS; i++)
This does look screwy. How can num_possible_nodes() possibly return
anything but "1" if CONFIG_NUMA=n.
Can we please get a code comment in here to explain things to the poor
old reader and to prevent people from trying to "fix" it?
Powered by blists - more mailing lists