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

2012-09-27 Thread Lai Jiangshan
SLUB only fucus on the nodes which has normal memory, so ignore the other
node's hot-adding and hot-removing.

Aka: if some memroy of a node(which has no onlined memory) is online,
but this new memory onlined is not normal memory(HIGH memory example),
we should not allocate kmem_cache_node for SLUB.

And if the last normal memory is offlined, but the node still has memroy,
we should remove kmem_cache_node for that node.(current code delay it when
all of the memory is offlined)

so we only do something when marg->status_change_nid_normal > 0.
marg->status_change_nid is not suitable here.

Signed-off-by: Lai Jiangshan 
---
 mm/slub.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index 2fdd96f..2d78639 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3577,7 +3577,7 @@ static void slab_mem_offline_callback(void *arg)
struct memory_notify *marg = arg;
int offline_node;
 
-   offline_node = marg->status_change_nid;
+   offline_node = marg->status_change_nid_normal;
 
/*
 * If the node still has available memory. we need kmem_cache_node
@@ -3610,7 +3610,7 @@ static int slab_mem_going_online_callback(void *arg)
struct kmem_cache_node *n;
struct kmem_cache *s;
struct memory_notify *marg = arg;
-   int nid = marg->status_change_nid;
+   int nid = marg->status_change_nid_normal;
int ret = 0;
 
/*
-- 
1.7.4.4

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


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

2012-10-24 Thread Lai Jiangshan
On 09/29/2012 06:26 AM, KOSAKI Motohiro wrote:
> On Fri, Sep 28, 2012 at 3:19 AM, Lai Jiangshan  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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2012-09-27 Thread KOSAKI Motohiro
(9/27/12 2:47 AM), Lai Jiangshan wrote:
> SLUB only fucus on the nodes which has normal memory, so ignore the other
> node's hot-adding and hot-removing.
> 
> Aka: if some memroy of a node(which has no onlined memory) is online,
> but this new memory onlined is not normal memory(HIGH memory example),
> we should not allocate kmem_cache_node for SLUB.
> 
> And if the last normal memory is offlined, but the node still has memroy,
> we should remove kmem_cache_node for that node.(current code delay it when
> all of the memory is offlined)
> 
> so we only do something when marg->status_change_nid_normal > 0.
> marg->status_change_nid is not suitable here.
> 
> Signed-off-by: Lai Jiangshan 
> ---
>  mm/slub.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 2fdd96f..2d78639 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -3577,7 +3577,7 @@ static void slab_mem_offline_callback(void *arg)
>   struct memory_notify *marg = arg;
>   int offline_node;
>  
> - offline_node = marg->status_change_nid;
> + offline_node = marg->status_change_nid_normal;
>  
>   /*
>* If the node still has available memory. we need kmem_cache_node
> @@ -3610,7 +3610,7 @@ static int slab_mem_going_online_callback(void *arg)
>   struct kmem_cache_node *n;
>   struct kmem_cache *s;
>   struct memory_notify *marg = arg;
> - int nid = marg->status_change_nid;
> + int nid = marg->status_change_nid_normal;
>   int ret = 0;

Looks reasonable. I think slab need similar fix too.




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


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

2012-09-27 Thread Christoph
While you are at it: Could you move the code into slab_common.c so that there 
is only one version to maintain?

On Sep 27, 2012, at 17:04, KOSAKI Motohiro  wrote:

> (9/27/12 2:47 AM), Lai Jiangshan wrote:
>> SLUB only fucus on the nodes which has normal memory, so ignore the other
>> node's hot-adding and hot-removing.
>> 
>> Aka: if some memroy of a node(which has no onlined memory) is online,
>> but this new memory onlined is not normal memory(HIGH memory example),
>> we should not allocate kmem_cache_node for SLUB.
>> 
>> And if the last normal memory is offlined, but the node still has memroy,
>> we should remove kmem_cache_node for that node.(current code delay it when
>> all of the memory is offlined)
>> 
>> so we only do something when marg->status_change_nid_normal > 0.
>> marg->status_change_nid is not suitable here.
>> 
>> Signed-off-by: Lai Jiangshan 
>> ---
>> mm/slub.c |4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/mm/slub.c b/mm/slub.c
>> index 2fdd96f..2d78639 100644
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
>> @@ -3577,7 +3577,7 @@ static void slab_mem_offline_callback(void *arg)
>>struct memory_notify *marg = arg;
>>int offline_node;
>> 
>> -offline_node = marg->status_change_nid;
>> +offline_node = marg->status_change_nid_normal;
>> 
>>/*
>> * If the node still has available memory. we need kmem_cache_node
>> @@ -3610,7 +3610,7 @@ static int slab_mem_going_online_callback(void *arg)
>>struct kmem_cache_node *n;
>>struct kmem_cache *s;
>>struct memory_notify *marg = arg;
>> -int nid = marg->status_change_nid;
>> +int nid = marg->status_change_nid_normal;
>>int ret = 0;
> 
> Looks reasonable. I think slab need similar fix too.
> 
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2012-09-28 Thread Lai Jiangshan
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.

Thanks,
Lai

On 09/28/2012 06:35 AM, Christoph wrote:
> While you are at it: Could you move the code into slab_common.c so that there 
> is only one version to maintain?
> 
> On Sep 27, 2012, at 17:04, KOSAKI Motohiro  wrote:
> 
>> (9/27/12 2:47 AM), Lai Jiangshan wrote:
>>> SLUB only fucus on the nodes which has normal memory, so ignore the other
>>> node's hot-adding and hot-removing.
>>>
>>> Aka: if some memroy of a node(which has no onlined memory) is online,
>>> but this new memory onlined is not normal memory(HIGH memory example),
>>> we should not allocate kmem_cache_node for SLUB.
>>>
>>> And if the last normal memory is offlined, but the node still has memroy,
>>> we should remove kmem_cache_node for that node.(current code delay it when
>>> all of the memory is offlined)
>>>
>>> so we only do something when marg->status_change_nid_normal > 0.
>>> marg->status_change_nid is not suitable here.
>>>
>>> Signed-off-by: Lai Jiangshan 
>>> ---
>>> mm/slub.c |4 ++--
>>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/mm/slub.c b/mm/slub.c
>>> index 2fdd96f..2d78639 100644
>>> --- a/mm/slub.c
>>> +++ b/mm/slub.c
>>> @@ -3577,7 +3577,7 @@ static void slab_mem_offline_callback(void *arg)
>>>struct memory_notify *marg = arg;
>>>int offline_node;
>>>
>>> -offline_node = marg->status_change_nid;
>>> +offline_node = marg->status_change_nid_normal;
>>>
>>>/*
>>> * If the node still has available memory. we need kmem_cache_node
>>> @@ -3610,7 +3610,7 @@ static int slab_mem_going_online_callback(void *arg)
>>>struct kmem_cache_node *n;
>>>struct kmem_cache *s;
>>>struct memory_notify *marg = arg;
>>> -int nid = marg->status_change_nid;
>>> +int nid = marg->status_change_nid_normal;
>>>int ret = 0;
>>
>> Looks reasonable. I think slab need similar fix too.
>>
>>
>>
> 

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


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

2012-09-28 Thread KOSAKI Motohiro
On Fri, Sep 28, 2012 at 3:19 AM, Lai Jiangshan  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.
If this is not bug, current slub behavior is also not bug. Is there
any difference?

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/