On Mon, 28 Mar 2016 14:26:52 +0900 js1304@xxxxxxxxx wrote:
> From: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
>
> 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?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>