Re: [PATCH 2/3] slub, hotplug: ignore unrelated node's hot-addingand hot-removing

[Lai Jiangshan]

On 09/29/2012 06:26 AM, KOSAKI Motohiro wrote:
> On Fri, Sep 28, 2012 at 3:19 AM, Lai Jiangshan <laijs@xxxxxxxxxxxxxx> wrote:
>> HI, Christoph, KOSAKI
>>
>> SLAB always allocates kmem_list3 for all nodes(N_HIGH_MEMORY), also node bug/bad things happens.
>> SLUB always requires kmem_cache_node on the correct node, so these fix is needed.
>>
>> SLAB uses for_each_online_node() to travel nodes and do maintain,
>> and it tolerates kmem_list3 on alien nodes.
>> SLUB uses for_each_node_state(node, N_NORMAL_MEMORY) to travel nodes and do maintain,
>> and it does not tolerate kmem_cache_node on alien nodes.
>>
>> Maybe we need to change SLAB future and let it use
>> for_each_node_state(node, N_NORMAL_MEMORY), But I don't want to change SLAB
>> until I find something bad in SLAB.
> 
> SLAB can't use highmem. then traverse zones which don't have normal
> memory is silly IMHO.

SLAB tolerates dummy kmem_list3 on alien nodes.

> If this is not bug, current slub behavior is also not bug. Is there
> any difference?

SLUB can't tolerates dummy kmem_cache_node on alien nodes, otherwise
n->nr_slabs will be corrupted when we online a node which don't have normal memory,
and trigger a WARN_ON(). And it will trigger BUG_ON() when we remove the node.

Since SLUB always use for_each_node_state(node, N_NORMAL_MEMORY), we should make
all the other code in slub.c be compatible with it. otherwise we will break the
design of SLUB.

Since SLAB always use for_each_online_node(), it means it accept some silly behavior
in the design, we don't need to change it before we decide to remove the whole
silly things at together. there is not waring and buggy in SLAB in this view.

> 
> If I understand correctly, current code may waste some additional
> memory on corner case. but it doesn't make memory leak both when slab
> and slub.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/