All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed

* [PATCH  0/2] Replace nr_node_ids for loop with for_each_node
@ 2015-09-08 18:31 ` Raghavendra K T
  0 siblings, 0 replies; 23+ messages in thread
From: Raghavendra K T @ 2015-09-08 18:31 UTC (permalink / raw)
  To: benh, paulus, mpe, anton, akpm
  Cc: nacc, gkurz, zhong, grant.likely, nikunj, vdavydov,
	raghavendra.kt, linuxppc-dev, linux-kernel, linux-mm

Many places in the kernel use 'for' loop with nr_node_ids. For the architectures
which supports sparse numa ids, this will result in some unnecessary allocations
for non existing nodes.
(for e.g., numa node numbers such as 0,1,16,17 is common in powerpc.)

So replace the for loop with for_each_node so that allocations happen only for
existing numa nodes.

Please note that, though there are many places where nr_node_ids is used,
current patchset uses for_each_node only for slowpath to avoid find_next_bit
traversal.

Raghavendra K T (2):
  mm: Replace nr_node_ids for loop with for_each_node in list lru
  powerpc:numa Do not allocate bootmem memory for non existing nodes

 arch/powerpc/mm/numa.c |  2 +-
 mm/list_lru.c          | 23 +++++++++++++++--------
 2 files changed, 16 insertions(+), 9 deletions(-)

-- 
1.7.11.7


^ permalink raw reply	[flat|nested] 23+ messages in thread

• * [PATCH  0/2] Replace nr_node_ids for loop with for_each_node
  @ 2015-09-08 18:31 ` Raghavendra K T
    0 siblings, 0 replies; 23+ messages in thread
  From: Raghavendra K T @ 2015-09-08 18:31 UTC (permalink / raw)
    To: benh, paulus, mpe, anton, akpm
    Cc: nacc, gkurz, zhong, grant.likely, nikunj, vdavydov,
  	raghavendra.kt, linuxppc-dev, linux-kernel, linux-mm
  
  Many places in the kernel use 'for' loop with nr_node_ids. For the architectures
  which supports sparse numa ids, this will result in some unnecessary allocations
  for non existing nodes.
  (for e.g., numa node numbers such as 0,1,16,17 is common in powerpc.)
  
  So replace the for loop with for_each_node so that allocations happen only for
  existing numa nodes.
  
  Please note that, though there are many places where nr_node_ids is used,
  current patchset uses for_each_node only for slowpath to avoid find_next_bit
  traversal.
  
  Raghavendra K T (2):
    mm: Replace nr_node_ids for loop with for_each_node in list lru
    powerpc:numa Do not allocate bootmem memory for non existing nodes
  
   arch/powerpc/mm/numa.c |  2 +-
   mm/list_lru.c          | 23 +++++++++++++++--------
   2 files changed, 16 insertions(+), 9 deletions(-)
  
  -- 
  1.7.11.7
  
  --
  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>
  
  ^ permalink raw reply	[flat|nested] 23+ messages in thread

• * [PATCH  1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru
    2015-09-08 18:31 ` Raghavendra K T
    (?)
  @ 2015-09-08 18:31   ` Raghavendra K T
    -1 siblings, 0 replies; 23+ messages in thread
  From: Raghavendra K T @ 2015-09-08 18:31 UTC (permalink / raw)
    To: benh, paulus, mpe, anton, akpm
    Cc: nacc, gkurz, zhong, grant.likely, nikunj, vdavydov,
  	raghavendra.kt, linuxppc-dev, linux-kernel, linux-mm
  
  The functions used in the patch are in slowpath, which gets called
  whenever alloc_super is called during mounts.
  
  Though this should not make difference for the architectures with
  sequential numa node ids, for the powerpc which can potentially have
  sparse node ids (for e.g., 4 node system having numa ids, 0,1,16,17
  is common), this patch saves some unnecessary allocations for
  non existing numa nodes.
  
  Even without that saving, perhaps patch makes code more readable.
  
  Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
  ---
   mm/list_lru.c | 23 +++++++++++++++--------
   1 file changed, 15 insertions(+), 8 deletions(-)
  
  diff --git a/mm/list_lru.c b/mm/list_lru.c
  index 909eca2..5a97f83 100644
  --- a/mm/list_lru.c
  +++ b/mm/list_lru.c
  @@ -377,7 +377,7 @@ static int memcg_init_list_lru(struct list_lru *lru, bool memcg_aware)
   {
   	int i;
   
  -	for (i = 0; i < nr_node_ids; i++) {
  +	for_each_node(i) {
   		if (!memcg_aware)
   			lru->node[i].memcg_lrus = NULL;
   		else if (memcg_init_list_lru_node(&lru->node[i]))
  @@ -385,8 +385,11 @@ static int memcg_init_list_lru(struct list_lru *lru, bool memcg_aware)
   	}
   	return 0;
   fail:
  -	for (i = i - 1; i >= 0; i--)
  +	for (i = i - 1; i >= 0; i--) {
  +		if (!lru->node[i].memcg_lrus)
  +			continue;
   		memcg_destroy_list_lru_node(&lru->node[i]);
  +	}
   	return -ENOMEM;
   }
   
  @@ -397,7 +400,7 @@ static void memcg_destroy_list_lru(struct list_lru *lru)
   	if (!list_lru_memcg_aware(lru))
   		return;
   
  -	for (i = 0; i < nr_node_ids; i++)
  +	for_each_node(i)
   		memcg_destroy_list_lru_node(&lru->node[i]);
   }
   
  @@ -409,16 +412,20 @@ static int memcg_update_list_lru(struct list_lru *lru,
   	if (!list_lru_memcg_aware(lru))
   		return 0;
   
  -	for (i = 0; i < nr_node_ids; i++) {
  +	for_each_node(i) {
   		if (memcg_update_list_lru_node(&lru->node[i],
   					       old_size, new_size))
   			goto fail;
   	}
   	return 0;
   fail:
  -	for (i = i - 1; i >= 0; i--)
  +	for (i = i - 1; i >= 0; i--) {
  +		if (!lru->node[i].memcg_lrus)
  +			continue;
  +
   		memcg_cancel_update_list_lru_node(&lru->node[i],
   						  old_size, new_size);
  +	}
   	return -ENOMEM;
   }
   
  @@ -430,7 +437,7 @@ static void memcg_cancel_update_list_lru(struct list_lru *lru,
   	if (!list_lru_memcg_aware(lru))
   		return;
   
  -	for (i = 0; i < nr_node_ids; i++)
  +	for_each_node(i)
   		memcg_cancel_update_list_lru_node(&lru->node[i],
   						  old_size, new_size);
   }
  @@ -485,7 +492,7 @@ static void memcg_drain_list_lru(struct list_lru *lru,
   	if (!list_lru_memcg_aware(lru))
   		return;
   
  -	for (i = 0; i < nr_node_ids; i++)
  +	for_each_node(i)
   		memcg_drain_list_lru_node(&lru->node[i], src_idx, dst_idx);
   }
   
  @@ -522,7 +529,7 @@ int __list_lru_init(struct list_lru *lru, bool memcg_aware,
   	if (!lru->node)
   		goto out;
   
  -	for (i = 0; i < nr_node_ids; i++) {
  +	for_each_node(i) {
   		spin_lock_init(&lru->node[i].lock);
   		if (key)
   			lockdep_set_class(&lru->node[i].lock, key);
  -- 
  1.7.11.7
  
  
  ^ permalink raw reply related	[flat|nested] 23+ messages in thread

• • * [PATCH 1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru
    @ 2015-09-08 18:31   ` Raghavendra K T
      0 siblings, 0 replies; 23+ messages in thread
    From: Raghavendra K T @ 2015-09-08 18:31 UTC (permalink / raw)
      To: benh, paulus, mpe, anton, akpm
      Cc: nacc, gkurz, zhong, grant.likely, nikunj, vdavydov,
    	raghavendra.kt, linuxppc-dev, linux-kernel, linux-mm
    
    The functions used in the patch are in slowpath, which gets called
    whenever alloc_super is called during mounts.
    
    Though this should not make difference for the architectures with
    sequential numa node ids, for the powerpc which can potentially have
    sparse node ids (for e.g., 4 node system having numa ids, 0,1,16,17
    is common), this patch saves some unnecessary allocations for
    non existing numa nodes.
    
    Even without that saving, perhaps patch makes code more readable.
    
    Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
    ---
     mm/list_lru.c | 23 +++++++++++++++--------
     1 file changed, 15 insertions(+), 8 deletions(-)
    
    diff --git a/mm/list_lru.c b/mm/list_lru.c
    index 909eca2..5a97f83 100644
    --- a/mm/list_lru.c
    +++ b/mm/list_lru.c
    @@ -377,7 +377,7 @@ static int memcg_init_list_lru(struct list_lru *lru, bool memcg_aware)
     {
     	int i;
     
    -	for (i = 0; i < nr_node_ids; i++) {
    +	for_each_node(i) {
     		if (!memcg_aware)
     			lru->node[i].memcg_lrus = NULL;
     		else if (memcg_init_list_lru_node(&lru->node[i]))
    @@ -385,8 +385,11 @@ static int memcg_init_list_lru(struct list_lru *lru, bool memcg_aware)
     	}
     	return 0;
     fail:
    -	for (i = i - 1; i >= 0; i--)
    +	for (i = i - 1; i >= 0; i--) {
    +		if (!lru->node[i].memcg_lrus)
    +			continue;
     		memcg_destroy_list_lru_node(&lru->node[i]);
    +	}
     	return -ENOMEM;
     }
     
    @@ -397,7 +400,7 @@ static void memcg_destroy_list_lru(struct list_lru *lru)
     	if (!list_lru_memcg_aware(lru))
     		return;
     
    -	for (i = 0; i < nr_node_ids; i++)
    +	for_each_node(i)
     		memcg_destroy_list_lru_node(&lru->node[i]);
     }
     
    @@ -409,16 +412,20 @@ static int memcg_update_list_lru(struct list_lru *lru,
     	if (!list_lru_memcg_aware(lru))
     		return 0;
     
    -	for (i = 0; i < nr_node_ids; i++) {
    +	for_each_node(i) {
     		if (memcg_update_list_lru_node(&lru->node[i],
     					       old_size, new_size))
     			goto fail;
     	}
     	return 0;
     fail:
    -	for (i = i - 1; i >= 0; i--)
    +	for (i = i - 1; i >= 0; i--) {
    +		if (!lru->node[i].memcg_lrus)
    +			continue;
    +
     		memcg_cancel_update_list_lru_node(&lru->node[i],
     						  old_size, new_size);
    +	}
     	return -ENOMEM;
     }
     
    @@ -430,7 +437,7 @@ static void memcg_cancel_update_list_lru(struct list_lru *lru,
     	if (!list_lru_memcg_aware(lru))
     		return;
     
    -	for (i = 0; i < nr_node_ids; i++)
    +	for_each_node(i)
     		memcg_cancel_update_list_lru_node(&lru->node[i],
     						  old_size, new_size);
     }
    @@ -485,7 +492,7 @@ static void memcg_drain_list_lru(struct list_lru *lru,
     	if (!list_lru_memcg_aware(lru))
     		return;
     
    -	for (i = 0; i < nr_node_ids; i++)
    +	for_each_node(i)
     		memcg_drain_list_lru_node(&lru->node[i], src_idx, dst_idx);
     }
     
    @@ -522,7 +529,7 @@ int __list_lru_init(struct list_lru *lru, bool memcg_aware,
     	if (!lru->node)
     		goto out;
     
    -	for (i = 0; i < nr_node_ids; i++) {
    +	for_each_node(i) {
     		spin_lock_init(&lru->node[i].lock);
     		if (key)
     			lockdep_set_class(&lru->node[i].lock, key);
    -- 
    1.7.11.7
    
    ^ permalink raw reply related	[flat|nested] 23+ messages in thread

  • * [PATCH  1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru
    @ 2015-09-08 18:31   ` Raghavendra K T
      0 siblings, 0 replies; 23+ messages in thread
    From: Raghavendra K T @ 2015-09-08 18:31 UTC (permalink / raw)
      To: benh, paulus, mpe, anton, akpm
      Cc: nacc, gkurz, zhong, grant.likely, nikunj, vdavydov,
    	raghavendra.kt, linuxppc-dev, linux-kernel, linux-mm
    
    The functions used in the patch are in slowpath, which gets called
    whenever alloc_super is called during mounts.
    
    Though this should not make difference for the architectures with
    sequential numa node ids, for the powerpc which can potentially have
    sparse node ids (for e.g., 4 node system having numa ids, 0,1,16,17
    is common), this patch saves some unnecessary allocations for
    non existing numa nodes.
    
    Even without that saving, perhaps patch makes code more readable.
    
    Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
    ---
     mm/list_lru.c | 23 +++++++++++++++--------
     1 file changed, 15 insertions(+), 8 deletions(-)
    
    diff --git a/mm/list_lru.c b/mm/list_lru.c
    index 909eca2..5a97f83 100644
    --- a/mm/list_lru.c
    +++ b/mm/list_lru.c
    @@ -377,7 +377,7 @@ static int memcg_init_list_lru(struct list_lru *lru, bool memcg_aware)
     {
     	int i;
     
    -	for (i = 0; i < nr_node_ids; i++) {
    +	for_each_node(i) {
     		if (!memcg_aware)
     			lru->node[i].memcg_lrus = NULL;
     		else if (memcg_init_list_lru_node(&lru->node[i]))
    @@ -385,8 +385,11 @@ static int memcg_init_list_lru(struct list_lru *lru, bool memcg_aware)
     	}
     	return 0;
     fail:
    -	for (i = i - 1; i >= 0; i--)
    +	for (i = i - 1; i >= 0; i--) {
    +		if (!lru->node[i].memcg_lrus)
    +			continue;
     		memcg_destroy_list_lru_node(&lru->node[i]);
    +	}
     	return -ENOMEM;
     }
     
    @@ -397,7 +400,7 @@ static void memcg_destroy_list_lru(struct list_lru *lru)
     	if (!list_lru_memcg_aware(lru))
     		return;
     
    -	for (i = 0; i < nr_node_ids; i++)
    +	for_each_node(i)
     		memcg_destroy_list_lru_node(&lru->node[i]);
     }
     
    @@ -409,16 +412,20 @@ static int memcg_update_list_lru(struct list_lru *lru,
     	if (!list_lru_memcg_aware(lru))
     		return 0;
     
    -	for (i = 0; i < nr_node_ids; i++) {
    +	for_each_node(i) {
     		if (memcg_update_list_lru_node(&lru->node[i],
     					       old_size, new_size))
     			goto fail;
     	}
     	return 0;
     fail:
    -	for (i = i - 1; i >= 0; i--)
    +	for (i = i - 1; i >= 0; i--) {
    +		if (!lru->node[i].memcg_lrus)
    +			continue;
    +
     		memcg_cancel_update_list_lru_node(&lru->node[i],
     						  old_size, new_size);
    +	}
     	return -ENOMEM;
     }
     
    @@ -430,7 +437,7 @@ static void memcg_cancel_update_list_lru(struct list_lru *lru,
     	if (!list_lru_memcg_aware(lru))
     		return;
     
    -	for (i = 0; i < nr_node_ids; i++)
    +	for_each_node(i)
     		memcg_cancel_update_list_lru_node(&lru->node[i],
     						  old_size, new_size);
     }
    @@ -485,7 +492,7 @@ static void memcg_drain_list_lru(struct list_lru *lru,
     	if (!list_lru_memcg_aware(lru))
     		return;
     
    -	for (i = 0; i < nr_node_ids; i++)
    +	for_each_node(i)
     		memcg_drain_list_lru_node(&lru->node[i], src_idx, dst_idx);
     }
     
    @@ -522,7 +529,7 @@ int __list_lru_init(struct list_lru *lru, bool memcg_aware,
     	if (!lru->node)
     		goto out;
     
    -	for (i = 0; i < nr_node_ids; i++) {
    +	for_each_node(i) {
     		spin_lock_init(&lru->node[i].lock);
     		if (key)
     			lockdep_set_class(&lru->node[i].lock, key);
    -- 
    1.7.11.7
    
    --
    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>
    
    ^ permalink raw reply related	[flat|nested] 23+ messages in thread

  • * Re: [PATCH  1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru
      2015-09-08 18:31   ` Raghavendra K T
      (?)
    @ 2015-09-14  9:00     ` Vladimir Davydov
      -1 siblings, 0 replies; 23+ messages in thread
    From: Vladimir Davydov @ 2015-09-14  9:00 UTC (permalink / raw)
      To: Raghavendra K T
      Cc: benh, paulus, mpe, anton, akpm, nacc, gkurz, zhong, grant.likely,
    	nikunj, linuxppc-dev, linux-kernel, linux-mm
    
    Hi,
    
    On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T wrote:
    > The functions used in the patch are in slowpath, which gets called
    > whenever alloc_super is called during mounts.
    > 
    > Though this should not make difference for the architectures with
    > sequential numa node ids, for the powerpc which can potentially have
    > sparse node ids (for e.g., 4 node system having numa ids, 0,1,16,17
    > is common), this patch saves some unnecessary allocations for
    > non existing numa nodes.
    > 
    > Even without that saving, perhaps patch makes code more readable.
    
    Do I understand correctly that node 0 must always be in
    node_possible_map? I ask, because we currently test
    lru->node[0].memcg_lrus to determine if the list is memcg aware.
    
    > 
    > Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
    > ---
    >  mm/list_lru.c | 23 +++++++++++++++--------
    >  1 file changed, 15 insertions(+), 8 deletions(-)
    > 
    > diff --git a/mm/list_lru.c b/mm/list_lru.c
    > index 909eca2..5a97f83 100644
    > --- a/mm/list_lru.c
    > +++ b/mm/list_lru.c
    > @@ -377,7 +377,7 @@ static int memcg_init_list_lru(struct list_lru *lru, bool memcg_aware)
    >  {
    >  	int i;
    >  
    > -	for (i = 0; i < nr_node_ids; i++) {
    > +	for_each_node(i) {
    >  		if (!memcg_aware)
    >  			lru->node[i].memcg_lrus = NULL;
    
    So, we don't explicitly initialize memcg_lrus for nodes that are not in
    node_possible_map. That's OK, because we allocate lru->node using
    kzalloc. However, this partial nullifying in case !memcg_aware looks
    confusing IMO. Let's drop it, I mean something like this:
    
    static int memcg_init_list_lru(struct list_lru *lru, bool memcg_aware)
    {
    	int i;
    
    	if (!memcg_aware)
    		return 0;
    
    	for_each_node(i) {
    		if (memcg_init_list_lru_node(&lru->node[i]))
    			goto fail;
    	}
    
    Thanks,
    Vladimir
    
    ^ permalink raw reply	[flat|nested] 23+ messages in thread

  • • * Re: [PATCH 1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru
      @ 2015-09-14  9:00     ` Vladimir Davydov
        0 siblings, 0 replies; 23+ messages in thread
      From: Vladimir Davydov @ 2015-09-14  9:00 UTC (permalink / raw)
        To: Raghavendra K T
        Cc: benh, paulus, mpe, anton, akpm, nacc, gkurz, zhong, grant.likely,
      	nikunj, linuxppc-dev, linux-kernel, linux-mm
      
      Hi,
      
      On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T wrote:
      > The functions used in the patch are in slowpath, which gets called
      > whenever alloc_super is called during mounts.
      > 
      > Though this should not make difference for the architectures with
      > sequential numa node ids, for the powerpc which can potentially have
      > sparse node ids (for e.g., 4 node system having numa ids, 0,1,16,17
      > is common), this patch saves some unnecessary allocations for
      > non existing numa nodes.
      > 
      > Even without that saving, perhaps patch makes code more readable.
      
      Do I understand correctly that node 0 must always be in
      node_possible_map? I ask, because we currently test
      lru->node[0].memcg_lrus to determine if the list is memcg aware.
      
      > 
      > Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
      > ---
      >  mm/list_lru.c | 23 +++++++++++++++--------
      >  1 file changed, 15 insertions(+), 8 deletions(-)
      > 
      > diff --git a/mm/list_lru.c b/mm/list_lru.c
      > index 909eca2..5a97f83 100644
      > --- a/mm/list_lru.c
      > +++ b/mm/list_lru.c
      > @@ -377,7 +377,7 @@ static int memcg_init_list_lru(struct list_lru *lru, bool memcg_aware)
      >  {
      >  	int i;
      >  
      > -	for (i = 0; i < nr_node_ids; i++) {
      > +	for_each_node(i) {
      >  		if (!memcg_aware)
      >  			lru->node[i].memcg_lrus = NULL;
      
      So, we don't explicitly initialize memcg_lrus for nodes that are not in
      node_possible_map. That's OK, because we allocate lru->node using
      kzalloc. However, this partial nullifying in case !memcg_aware looks
      confusing IMO. Let's drop it, I mean something like this:
      
      static int memcg_init_list_lru(struct list_lru *lru, bool memcg_aware)
      {
      	int i;
      
      	if (!memcg_aware)
      		return 0;
      
      	for_each_node(i) {
      		if (memcg_init_list_lru_node(&lru->node[i]))
      			goto fail;
      	}
      
      Thanks,
      Vladimir
      
      ^ permalink raw reply	[flat|nested] 23+ messages in thread

    • * Re: [PATCH  1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru
      @ 2015-09-14  9:00     ` Vladimir Davydov
        0 siblings, 0 replies; 23+ messages in thread
      From: Vladimir Davydov @ 2015-09-14  9:00 UTC (permalink / raw)
        To: Raghavendra K T
        Cc: benh, paulus, mpe, anton, akpm, nacc, gkurz, zhong, grant.likely,
      	nikunj, linuxppc-dev, linux-kernel, linux-mm
      
      Hi,
      
      On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T wrote:
      > The functions used in the patch are in slowpath, which gets called
      > whenever alloc_super is called during mounts.
      > 
      > Though this should not make difference for the architectures with
      > sequential numa node ids, for the powerpc which can potentially have
      > sparse node ids (for e.g., 4 node system having numa ids, 0,1,16,17
      > is common), this patch saves some unnecessary allocations for
      > non existing numa nodes.
      > 
      > Even without that saving, perhaps patch makes code more readable.
      
      Do I understand correctly that node 0 must always be in
      node_possible_map? I ask, because we currently test
      lru->node[0].memcg_lrus to determine if the list is memcg aware.
      
      > 
      > Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
      > ---
      >  mm/list_lru.c | 23 +++++++++++++++--------
      >  1 file changed, 15 insertions(+), 8 deletions(-)
      > 
      > diff --git a/mm/list_lru.c b/mm/list_lru.c
      > index 909eca2..5a97f83 100644
      > --- a/mm/list_lru.c
      > +++ b/mm/list_lru.c
      > @@ -377,7 +377,7 @@ static int memcg_init_list_lru(struct list_lru *lru, bool memcg_aware)
      >  {
      >  	int i;
      >  
      > -	for (i = 0; i < nr_node_ids; i++) {
      > +	for_each_node(i) {
      >  		if (!memcg_aware)
      >  			lru->node[i].memcg_lrus = NULL;
      
      So, we don't explicitly initialize memcg_lrus for nodes that are not in
      node_possible_map. That's OK, because we allocate lru->node using
      kzalloc. However, this partial nullifying in case !memcg_aware looks
      confusing IMO. Let's drop it, I mean something like this:
      
      static int memcg_init_list_lru(struct list_lru *lru, bool memcg_aware)
      {
      	int i;
      
      	if (!memcg_aware)
      		return 0;
      
      	for_each_node(i) {
      		if (memcg_init_list_lru_node(&lru->node[i]))
      			goto fail;
      	}
      
      Thanks,
      Vladimir
      
      --
      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>
      
      ^ permalink raw reply	[flat|nested] 23+ messages in thread

    • * Re: [PATCH  1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru
        2015-09-14  9:00     ` Vladimir Davydov
        (?)
      @ 2015-09-14 11:39       ` Raghavendra K T
        -1 siblings, 0 replies; 23+ messages in thread
      From: Raghavendra K T @ 2015-09-14 11:39 UTC (permalink / raw)
        To: Vladimir Davydov
        Cc: benh, paulus, mpe, anton, akpm, nacc, gkurz, zhong, grant.likely,
      	nikunj, linuxppc-dev, linux-kernel, linux-mm
      
      On 09/14/2015 02:30 PM, Vladimir Davydov wrote:
      > Hi,
      >
      > On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T wrote:
      >> The functions used in the patch are in slowpath, which gets called
      >> whenever alloc_super is called during mounts.
      >>
      >> Though this should not make difference for the architectures with
      >> sequential numa node ids, for the powerpc which can potentially have
      >> sparse node ids (for e.g., 4 node system having numa ids, 0,1,16,17
      >> is common), this patch saves some unnecessary allocations for
      >> non existing numa nodes.
      >>
      >> Even without that saving, perhaps patch makes code more readable.
      >
      > Do I understand correctly that node 0 must always be in
      > node_possible_map? I ask, because we currently test
      > lru->node[0].memcg_lrus to determine if the list is memcg aware.
      >
      
      Yes, node 0 is always there. So it should not be a problem.
      
      >>
      >> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
      >> ---
      >>   mm/list_lru.c | 23 +++++++++++++++--------
      >>   1 file changed, 15 insertions(+), 8 deletions(-)
      >>
      >> diff --git a/mm/list_lru.c b/mm/list_lru.c
      >> index 909eca2..5a97f83 100644
      >> --- a/mm/list_lru.c
      >> +++ b/mm/list_lru.c
      >> @@ -377,7 +377,7 @@ static int memcg_init_list_lru(struct list_lru *lru, bool memcg_aware)
      >>   {
      >>   	int i;
      >>
      >> -	for (i = 0; i < nr_node_ids; i++) {
      >> +	for_each_node(i) {
      >>   		if (!memcg_aware)
      >>   			lru->node[i].memcg_lrus = NULL;
      >
      > So, we don't explicitly initialize memcg_lrus for nodes that are not in
      > node_possible_map. That's OK, because we allocate lru->node using
      > kzalloc. However, this partial nullifying in case !memcg_aware looks
      > confusing IMO. Let's drop it, I mean something like this:
      
      Yes, you are right. and we do not have to have memcg_aware check inside
      for loop too.
      Will change as per your suggestion and send V2.
      Thanks for the review.
      
      >
      > static int memcg_init_list_lru(struct list_lru *lru, bool memcg_aware)
      > {
      > 	int i;
      >
      > 	if (!memcg_aware)
      > 		return 0;
      >
      > 	for_each_node(i) {
      > 		if (memcg_init_list_lru_node(&lru->node[i]))
      > 			goto fail;
      > 	}
      >
      
      
      ^ permalink raw reply	[flat|nested] 23+ messages in thread

    • • * Re: [PATCH 1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru
        @ 2015-09-14 11:39       ` Raghavendra K T
          0 siblings, 0 replies; 23+ messages in thread
        From: Raghavendra K T @ 2015-09-14 11:39 UTC (permalink / raw)
          To: Vladimir Davydov
          Cc: benh, paulus, mpe, anton, akpm, nacc, gkurz, zhong, grant.likely,
        	nikunj, linuxppc-dev, linux-kernel, linux-mm
        
        On 09/14/2015 02:30 PM, Vladimir Davydov wrote:
        > Hi,
        >
        > On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T wrote:
        >> The functions used in the patch are in slowpath, which gets called
        >> whenever alloc_super is called during mounts.
        >>
        >> Though this should not make difference for the architectures with
        >> sequential numa node ids, for the powerpc which can potentially have
        >> sparse node ids (for e.g., 4 node system having numa ids, 0,1,16,17
        >> is common), this patch saves some unnecessary allocations for
        >> non existing numa nodes.
        >>
        >> Even without that saving, perhaps patch makes code more readable.
        >
        > Do I understand correctly that node 0 must always be in
        > node_possible_map? I ask, because we currently test
        > lru->node[0].memcg_lrus to determine if the list is memcg aware.
        >
        
        Yes, node 0 is always there. So it should not be a problem.
        
        >>
        >> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
        >> ---
        >>   mm/list_lru.c | 23 +++++++++++++++--------
        >>   1 file changed, 15 insertions(+), 8 deletions(-)
        >>
        >> diff --git a/mm/list_lru.c b/mm/list_lru.c
        >> index 909eca2..5a97f83 100644
        >> --- a/mm/list_lru.c
        >> +++ b/mm/list_lru.c
        >> @@ -377,7 +377,7 @@ static int memcg_init_list_lru(struct list_lru *lru, bool memcg_aware)
        >>   {
        >>   	int i;
        >>
        >> -	for (i = 0; i < nr_node_ids; i++) {
        >> +	for_each_node(i) {
        >>   		if (!memcg_aware)
        >>   			lru->node[i].memcg_lrus = NULL;
        >
        > So, we don't explicitly initialize memcg_lrus for nodes that are not in
        > node_possible_map. That's OK, because we allocate lru->node using
        > kzalloc. However, this partial nullifying in case !memcg_aware looks
        > confusing IMO. Let's drop it, I mean something like this:
        
        Yes, you are right. and we do not have to have memcg_aware check inside
        for loop too.
        Will change as per your suggestion and send V2.
        Thanks for the review.
        
        >
        > static int memcg_init_list_lru(struct list_lru *lru, bool memcg_aware)
        > {
        > 	int i;
        >
        > 	if (!memcg_aware)
        > 		return 0;
        >
        > 	for_each_node(i) {
        > 		if (memcg_init_list_lru_node(&lru->node[i]))
        > 			goto fail;
        > 	}
        >
        
        ^ permalink raw reply	[flat|nested] 23+ messages in thread

      • * Re: [PATCH  1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru
        @ 2015-09-14 11:39       ` Raghavendra K T
          0 siblings, 0 replies; 23+ messages in thread
        From: Raghavendra K T @ 2015-09-14 11:39 UTC (permalink / raw)
          To: Vladimir Davydov
          Cc: benh, paulus, mpe, anton, akpm, nacc, gkurz, zhong, grant.likely,
        	nikunj, linuxppc-dev, linux-kernel, linux-mm
        
        On 09/14/2015 02:30 PM, Vladimir Davydov wrote:
        > Hi,
        >
        > On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T wrote:
        >> The functions used in the patch are in slowpath, which gets called
        >> whenever alloc_super is called during mounts.
        >>
        >> Though this should not make difference for the architectures with
        >> sequential numa node ids, for the powerpc which can potentially have
        >> sparse node ids (for e.g., 4 node system having numa ids, 0,1,16,17
        >> is common), this patch saves some unnecessary allocations for
        >> non existing numa nodes.
        >>
        >> Even without that saving, perhaps patch makes code more readable.
        >
        > Do I understand correctly that node 0 must always be in
        > node_possible_map? I ask, because we currently test
        > lru->node[0].memcg_lrus to determine if the list is memcg aware.
        >
        
        Yes, node 0 is always there. So it should not be a problem.
        
        >>
        >> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
        >> ---
        >>   mm/list_lru.c | 23 +++++++++++++++--------
        >>   1 file changed, 15 insertions(+), 8 deletions(-)
        >>
        >> diff --git a/mm/list_lru.c b/mm/list_lru.c
        >> index 909eca2..5a97f83 100644
        >> --- a/mm/list_lru.c
        >> +++ b/mm/list_lru.c
        >> @@ -377,7 +377,7 @@ static int memcg_init_list_lru(struct list_lru *lru, bool memcg_aware)
        >>   {
        >>   	int i;
        >>
        >> -	for (i = 0; i < nr_node_ids; i++) {
        >> +	for_each_node(i) {
        >>   		if (!memcg_aware)
        >>   			lru->node[i].memcg_lrus = NULL;
        >
        > So, we don't explicitly initialize memcg_lrus for nodes that are not in
        > node_possible_map. That's OK, because we allocate lru->node using
        > kzalloc. However, this partial nullifying in case !memcg_aware looks
        > confusing IMO. Let's drop it, I mean something like this:
        
        Yes, you are right. and we do not have to have memcg_aware check inside
        for loop too.
        Will change as per your suggestion and send V2.
        Thanks for the review.
        
        >
        > static int memcg_init_list_lru(struct list_lru *lru, bool memcg_aware)
        > {
        > 	int i;
        >
        > 	if (!memcg_aware)
        > 		return 0;
        >
        > 	for_each_node(i) {
        > 		if (memcg_init_list_lru_node(&lru->node[i]))
        > 			goto fail;
        > 	}
        >
        
        --
        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>
        
        ^ permalink raw reply	[flat|nested] 23+ messages in thread

      • * Re: [PATCH  1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru
          2015-09-14 11:39       ` Raghavendra K T
          (?)
        @ 2015-09-14 12:04         ` Vladimir Davydov
          -1 siblings, 0 replies; 23+ messages in thread
        From: Vladimir Davydov @ 2015-09-14 12:04 UTC (permalink / raw)
          To: Raghavendra K T
          Cc: benh, paulus, mpe, anton, akpm, nacc, gkurz, zhong, grant.likely,
        	nikunj, linuxppc-dev, linux-kernel, linux-mm
        
        On Mon, Sep 14, 2015 at 05:09:31PM +0530, Raghavendra K T wrote:
        > On 09/14/2015 02:30 PM, Vladimir Davydov wrote:
        > >On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T wrote:
        > >>The functions used in the patch are in slowpath, which gets called
        > >>whenever alloc_super is called during mounts.
        > >>
        > >>Though this should not make difference for the architectures with
        > >>sequential numa node ids, for the powerpc which can potentially have
        > >>sparse node ids (for e.g., 4 node system having numa ids, 0,1,16,17
        > >>is common), this patch saves some unnecessary allocations for
        > >>non existing numa nodes.
        > >>
        > >>Even without that saving, perhaps patch makes code more readable.
        > >
        > >Do I understand correctly that node 0 must always be in
        > >node_possible_map? I ask, because we currently test
        > >lru->node[0].memcg_lrus to determine if the list is memcg aware.
        > >
        > 
        > Yes, node 0 is always there. So it should not be a problem.
        
        I think it should be mentioned in the comment to list_lru_memcg_aware
        then.
        
        Thanks,
        Vladimir
        
        ^ permalink raw reply	[flat|nested] 23+ messages in thread

      • • * Re: [PATCH 1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru
          @ 2015-09-14 12:04         ` Vladimir Davydov
            0 siblings, 0 replies; 23+ messages in thread
          From: Vladimir Davydov @ 2015-09-14 12:04 UTC (permalink / raw)
            To: Raghavendra K T
            Cc: benh, paulus, mpe, anton, akpm, nacc, gkurz, zhong, grant.likely,
          	nikunj, linuxppc-dev, linux-kernel, linux-mm
          
          On Mon, Sep 14, 2015 at 05:09:31PM +0530, Raghavendra K T wrote:
          > On 09/14/2015 02:30 PM, Vladimir Davydov wrote:
          > >On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T wrote:
          > >>The functions used in the patch are in slowpath, which gets called
          > >>whenever alloc_super is called during mounts.
          > >>
          > >>Though this should not make difference for the architectures with
          > >>sequential numa node ids, for the powerpc which can potentially have
          > >>sparse node ids (for e.g., 4 node system having numa ids, 0,1,16,17
          > >>is common), this patch saves some unnecessary allocations for
          > >>non existing numa nodes.
          > >>
          > >>Even without that saving, perhaps patch makes code more readable.
          > >
          > >Do I understand correctly that node 0 must always be in
          > >node_possible_map? I ask, because we currently test
          > >lru->node[0].memcg_lrus to determine if the list is memcg aware.
          > >
          > 
          > Yes, node 0 is always there. So it should not be a problem.
          
          I think it should be mentioned in the comment to list_lru_memcg_aware
          then.
          
          Thanks,
          Vladimir
          
          ^ permalink raw reply	[flat|nested] 23+ messages in thread

        • * Re: [PATCH  1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru
          @ 2015-09-14 12:04         ` Vladimir Davydov
            0 siblings, 0 replies; 23+ messages in thread
          From: Vladimir Davydov @ 2015-09-14 12:04 UTC (permalink / raw)
            To: Raghavendra K T
            Cc: benh, paulus, mpe, anton, akpm, nacc, gkurz, zhong, grant.likely,
          	nikunj, linuxppc-dev, linux-kernel, linux-mm
          
          On Mon, Sep 14, 2015 at 05:09:31PM +0530, Raghavendra K T wrote:
          > On 09/14/2015 02:30 PM, Vladimir Davydov wrote:
          > >On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T wrote:
          > >>The functions used in the patch are in slowpath, which gets called
          > >>whenever alloc_super is called during mounts.
          > >>
          > >>Though this should not make difference for the architectures with
          > >>sequential numa node ids, for the powerpc which can potentially have
          > >>sparse node ids (for e.g., 4 node system having numa ids, 0,1,16,17
          > >>is common), this patch saves some unnecessary allocations for
          > >>non existing numa nodes.
          > >>
          > >>Even without that saving, perhaps patch makes code more readable.
          > >
          > >Do I understand correctly that node 0 must always be in
          > >node_possible_map? I ask, because we currently test
          > >lru->node[0].memcg_lrus to determine if the list is memcg aware.
          > >
          > 
          > Yes, node 0 is always there. So it should not be a problem.
          
          I think it should be mentioned in the comment to list_lru_memcg_aware
          then.
          
          Thanks,
          Vladimir
          
          --
          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>
          
          ^ permalink raw reply	[flat|nested] 23+ messages in thread

        • * Re: [PATCH  1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru
            2015-09-14 12:04         ` Vladimir Davydov
            (?)
          @ 2015-09-14 13:05           ` Raghavendra K T
            -1 siblings, 0 replies; 23+ messages in thread
          From: Raghavendra K T @ 2015-09-14 13:05 UTC (permalink / raw)
            To: Vladimir Davydov
            Cc: benh, paulus, mpe, anton, akpm, nacc, gkurz, zhong, grant.likely,
          	nikunj, linuxppc-dev, linux-kernel, linux-mm
          
          On 09/14/2015 05:34 PM, Vladimir Davydov wrote:
          > On Mon, Sep 14, 2015 at 05:09:31PM +0530, Raghavendra K T wrote:
          >> On 09/14/2015 02:30 PM, Vladimir Davydov wrote:
          >>> On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T wrote:
          >>>> The functions used in the patch are in slowpath, which gets called
          >>>> whenever alloc_super is called during mounts.
          >>>>
          >>>> Though this should not make difference for the architectures with
          >>>> sequential numa node ids, for the powerpc which can potentially have
          >>>> sparse node ids (for e.g., 4 node system having numa ids, 0,1,16,17
          >>>> is common), this patch saves some unnecessary allocations for
          >>>> non existing numa nodes.
          >>>>
          >>>> Even without that saving, perhaps patch makes code more readable.
          >>>
          >>> Do I understand correctly that node 0 must always be in
          >>> node_possible_map? I ask, because we currently test
          >>> lru->node[0].memcg_lrus to determine if the list is memcg aware.
          >>>
          >>
          >> Yes, node 0 is always there. So it should not be a problem.
          >
          > I think it should be mentioned in the comment to list_lru_memcg_aware
          > then.
          >
          
          Something like this: ?
          static inline bool list_lru_memcg_aware(struct list_lru *lru)
          {
                   /*
                    * This needs node 0 to be always present, even
                    * in the systems supporting sparse numa ids.
                    */
                   return !!lru->node[0].memcg_lrus;
          }
          
          
          
          ^ permalink raw reply	[flat|nested] 23+ messages in thread

        • • * Re: [PATCH 1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru
            @ 2015-09-14 13:05           ` Raghavendra K T
              0 siblings, 0 replies; 23+ messages in thread
            From: Raghavendra K T @ 2015-09-14 13:05 UTC (permalink / raw)
              To: Vladimir Davydov
              Cc: benh, paulus, mpe, anton, akpm, nacc, gkurz, zhong, grant.likely,
            	nikunj, linuxppc-dev, linux-kernel, linux-mm
            
            On 09/14/2015 05:34 PM, Vladimir Davydov wrote:
            > On Mon, Sep 14, 2015 at 05:09:31PM +0530, Raghavendra K T wrote:
            >> On 09/14/2015 02:30 PM, Vladimir Davydov wrote:
            >>> On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T wrote:
            >>>> The functions used in the patch are in slowpath, which gets called
            >>>> whenever alloc_super is called during mounts.
            >>>>
            >>>> Though this should not make difference for the architectures with
            >>>> sequential numa node ids, for the powerpc which can potentially have
            >>>> sparse node ids (for e.g., 4 node system having numa ids, 0,1,16,17
            >>>> is common), this patch saves some unnecessary allocations for
            >>>> non existing numa nodes.
            >>>>
            >>>> Even without that saving, perhaps patch makes code more readable.
            >>>
            >>> Do I understand correctly that node 0 must always be in
            >>> node_possible_map? I ask, because we currently test
            >>> lru->node[0].memcg_lrus to determine if the list is memcg aware.
            >>>
            >>
            >> Yes, node 0 is always there. So it should not be a problem.
            >
            > I think it should be mentioned in the comment to list_lru_memcg_aware
            > then.
            >
            
            Something like this: ?
            static inline bool list_lru_memcg_aware(struct list_lru *lru)
            {
                     /*
                      * This needs node 0 to be always present, even
                      * in the systems supporting sparse numa ids.
                      */
                     return !!lru->node[0].memcg_lrus;
            }
            
            ^ permalink raw reply	[flat|nested] 23+ messages in thread

          • * Re: [PATCH  1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru
            @ 2015-09-14 13:05           ` Raghavendra K T
              0 siblings, 0 replies; 23+ messages in thread
            From: Raghavendra K T @ 2015-09-14 13:05 UTC (permalink / raw)
              To: Vladimir Davydov
              Cc: benh, paulus, mpe, anton, akpm, nacc, gkurz, zhong, grant.likely,
            	nikunj, linuxppc-dev, linux-kernel, linux-mm
            
            On 09/14/2015 05:34 PM, Vladimir Davydov wrote:
            > On Mon, Sep 14, 2015 at 05:09:31PM +0530, Raghavendra K T wrote:
            >> On 09/14/2015 02:30 PM, Vladimir Davydov wrote:
            >>> On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T wrote:
            >>>> The functions used in the patch are in slowpath, which gets called
            >>>> whenever alloc_super is called during mounts.
            >>>>
            >>>> Though this should not make difference for the architectures with
            >>>> sequential numa node ids, for the powerpc which can potentially have
            >>>> sparse node ids (for e.g., 4 node system having numa ids, 0,1,16,17
            >>>> is common), this patch saves some unnecessary allocations for
            >>>> non existing numa nodes.
            >>>>
            >>>> Even without that saving, perhaps patch makes code more readable.
            >>>
            >>> Do I understand correctly that node 0 must always be in
            >>> node_possible_map? I ask, because we currently test
            >>> lru->node[0].memcg_lrus to determine if the list is memcg aware.
            >>>
            >>
            >> Yes, node 0 is always there. So it should not be a problem.
            >
            > I think it should be mentioned in the comment to list_lru_memcg_aware
            > then.
            >
            
            Something like this: ?
            static inline bool list_lru_memcg_aware(struct list_lru *lru)
            {
                     /*
                      * This needs node 0 to be always present, even
                      * in the systems supporting sparse numa ids.
                      */
                     return !!lru->node[0].memcg_lrus;
            }
            
            
            --
            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>
            
            ^ permalink raw reply	[flat|nested] 23+ messages in thread

          • * Re: [PATCH  1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru
              2015-09-14 13:05           ` Raghavendra K T
              (?)
            @ 2015-09-14 13:27             ` Vladimir Davydov
              -1 siblings, 0 replies; 23+ messages in thread
            From: Vladimir Davydov @ 2015-09-14 13:27 UTC (permalink / raw)
              To: Raghavendra K T
              Cc: benh, paulus, mpe, anton, akpm, nacc, gkurz, zhong, grant.likely,
            	nikunj, linuxppc-dev, linux-kernel, linux-mm
            
            On Mon, Sep 14, 2015 at 06:35:59PM +0530, Raghavendra K T wrote:
            > On 09/14/2015 05:34 PM, Vladimir Davydov wrote:
            > >On Mon, Sep 14, 2015 at 05:09:31PM +0530, Raghavendra K T wrote:
            > >>On 09/14/2015 02:30 PM, Vladimir Davydov wrote:
            > >>>On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T wrote:
            > >>>>The functions used in the patch are in slowpath, which gets called
            > >>>>whenever alloc_super is called during mounts.
            > >>>>
            > >>>>Though this should not make difference for the architectures with
            > >>>>sequential numa node ids, for the powerpc which can potentially have
            > >>>>sparse node ids (for e.g., 4 node system having numa ids, 0,1,16,17
            > >>>>is common), this patch saves some unnecessary allocations for
            > >>>>non existing numa nodes.
            > >>>>
            > >>>>Even without that saving, perhaps patch makes code more readable.
            > >>>
            > >>>Do I understand correctly that node 0 must always be in
            > >>>node_possible_map? I ask, because we currently test
            > >>>lru->node[0].memcg_lrus to determine if the list is memcg aware.
            > >>>
            > >>
            > >>Yes, node 0 is always there. So it should not be a problem.
            > >
            > >I think it should be mentioned in the comment to list_lru_memcg_aware
            > >then.
            > >
            > 
            > Something like this: ?
            
            Yeah, looks good to me.
            
            Thanks,
            Vladimir
            
            > static inline bool list_lru_memcg_aware(struct list_lru *lru)
            > {
            >         /*
            >          * This needs node 0 to be always present, even
            >          * in the systems supporting sparse numa ids.
            >          */
            >         return !!lru->node[0].memcg_lrus;
            > }
            > 
            > 
            
            ^ permalink raw reply	[flat|nested] 23+ messages in thread

          • • * Re: [PATCH 1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru
              @ 2015-09-14 13:27             ` Vladimir Davydov
                0 siblings, 0 replies; 23+ messages in thread
              From: Vladimir Davydov @ 2015-09-14 13:27 UTC (permalink / raw)
                To: Raghavendra K T
                Cc: benh, paulus, mpe, anton, akpm, nacc, gkurz, zhong, grant.likely,
              	nikunj, linuxppc-dev, linux-kernel, linux-mm
              
              On Mon, Sep 14, 2015 at 06:35:59PM +0530, Raghavendra K T wrote:
              > On 09/14/2015 05:34 PM, Vladimir Davydov wrote:
              > >On Mon, Sep 14, 2015 at 05:09:31PM +0530, Raghavendra K T wrote:
              > >>On 09/14/2015 02:30 PM, Vladimir Davydov wrote:
              > >>>On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T wrote:
              > >>>>The functions used in the patch are in slowpath, which gets called
              > >>>>whenever alloc_super is called during mounts.
              > >>>>
              > >>>>Though this should not make difference for the architectures with
              > >>>>sequential numa node ids, for the powerpc which can potentially have
              > >>>>sparse node ids (for e.g., 4 node system having numa ids, 0,1,16,17
              > >>>>is common), this patch saves some unnecessary allocations for
              > >>>>non existing numa nodes.
              > >>>>
              > >>>>Even without that saving, perhaps patch makes code more readable.
              > >>>
              > >>>Do I understand correctly that node 0 must always be in
              > >>>node_possible_map? I ask, because we currently test
              > >>>lru->node[0].memcg_lrus to determine if the list is memcg aware.
              > >>>
              > >>
              > >>Yes, node 0 is always there. So it should not be a problem.
              > >
              > >I think it should be mentioned in the comment to list_lru_memcg_aware
              > >then.
              > >
              > 
              > Something like this: ?
              
              Yeah, looks good to me.
              
              Thanks,
              Vladimir
              
              > static inline bool list_lru_memcg_aware(struct list_lru *lru)
              > {
              >         /*
              >          * This needs node 0 to be always present, even
              >          * in the systems supporting sparse numa ids.
              >          */
              >         return !!lru->node[0].memcg_lrus;
              > }
              > 
              > 
              
              ^ permalink raw reply	[flat|nested] 23+ messages in thread

            • * Re: [PATCH  1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru
              @ 2015-09-14 13:27             ` Vladimir Davydov
                0 siblings, 0 replies; 23+ messages in thread
              From: Vladimir Davydov @ 2015-09-14 13:27 UTC (permalink / raw)
                To: Raghavendra K T
                Cc: benh, paulus, mpe, anton, akpm, nacc, gkurz, zhong, grant.likely,
              	nikunj, linuxppc-dev, linux-kernel, linux-mm
              
              On Mon, Sep 14, 2015 at 06:35:59PM +0530, Raghavendra K T wrote:
              > On 09/14/2015 05:34 PM, Vladimir Davydov wrote:
              > >On Mon, Sep 14, 2015 at 05:09:31PM +0530, Raghavendra K T wrote:
              > >>On 09/14/2015 02:30 PM, Vladimir Davydov wrote:
              > >>>On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T wrote:
              > >>>>The functions used in the patch are in slowpath, which gets called
              > >>>>whenever alloc_super is called during mounts.
              > >>>>
              > >>>>Though this should not make difference for the architectures with
              > >>>>sequential numa node ids, for the powerpc which can potentially have
              > >>>>sparse node ids (for e.g., 4 node system having numa ids, 0,1,16,17
              > >>>>is common), this patch saves some unnecessary allocations for
              > >>>>non existing numa nodes.
              > >>>>
              > >>>>Even without that saving, perhaps patch makes code more readable.
              > >>>
              > >>>Do I understand correctly that node 0 must always be in
              > >>>node_possible_map? I ask, because we currently test
              > >>>lru->node[0].memcg_lrus to determine if the list is memcg aware.
              > >>>
              > >>
              > >>Yes, node 0 is always there. So it should not be a problem.
              > >
              > >I think it should be mentioned in the comment to list_lru_memcg_aware
              > >then.
              > >
              > 
              > Something like this: ?
              
              Yeah, looks good to me.
              
              Thanks,
              Vladimir
              
              > static inline bool list_lru_memcg_aware(struct list_lru *lru)
              > {
              >         /*
              >          * This needs node 0 to be always present, even
              >          * in the systems supporting sparse numa ids.
              >          */
              >         return !!lru->node[0].memcg_lrus;
              > }
              > 
              > 
              
              --
              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>
              
              ^ permalink raw reply	[flat|nested] 23+ messages in thread

• * [PATCH  2/2] powerpc:numa Do not allocate bootmem memory for non existing nodes
    2015-09-08 18:31 ` Raghavendra K T
    (?)
  @ 2015-09-08 18:31   ` Raghavendra K T
    -1 siblings, 0 replies; 23+ messages in thread
  From: Raghavendra K T @ 2015-09-08 18:31 UTC (permalink / raw)
    To: benh, paulus, mpe, anton, akpm
    Cc: nacc, gkurz, zhong, grant.likely, nikunj, vdavydov,
  	raghavendra.kt, linuxppc-dev, linux-kernel, linux-mm
  
  Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
  ---
   arch/powerpc/mm/numa.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
  index 8b9502a..8d8a541 100644
  --- a/arch/powerpc/mm/numa.c
  +++ b/arch/powerpc/mm/numa.c
  @@ -80,7 +80,7 @@ static void __init setup_node_to_cpumask_map(void)
   		setup_nr_node_ids();
   
   	/* allocate the map */
  -	for (node = 0; node < nr_node_ids; node++)
  +	for_each_node(node)
   		alloc_bootmem_cpumask_var(&node_to_cpumask_map[node]);
   
   	/* cpumask_of_node() will now work */
  -- 
  1.7.11.7
  
  
  ^ permalink raw reply related	[flat|nested] 23+ messages in thread

• • * [PATCH 2/2] powerpc:numa Do not allocate bootmem memory for non existing nodes
    @ 2015-09-08 18:31   ` Raghavendra K T
      0 siblings, 0 replies; 23+ messages in thread
    From: Raghavendra K T @ 2015-09-08 18:31 UTC (permalink / raw)
      To: benh, paulus, mpe, anton, akpm
      Cc: nacc, gkurz, zhong, grant.likely, nikunj, vdavydov,
    	raghavendra.kt, linuxppc-dev, linux-kernel, linux-mm
    
    Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
    ---
     arch/powerpc/mm/numa.c | 2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)
    
    diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
    index 8b9502a..8d8a541 100644
    --- a/arch/powerpc/mm/numa.c
    +++ b/arch/powerpc/mm/numa.c
    @@ -80,7 +80,7 @@ static void __init setup_node_to_cpumask_map(void)
     		setup_nr_node_ids();
     
     	/* allocate the map */
    -	for (node = 0; node < nr_node_ids; node++)
    +	for_each_node(node)
     		alloc_bootmem_cpumask_var(&node_to_cpumask_map[node]);
     
     	/* cpumask_of_node() will now work */
    -- 
    1.7.11.7
    
    ^ permalink raw reply related	[flat|nested] 23+ messages in thread

  • * [PATCH  2/2] powerpc:numa Do not allocate bootmem memory for non existing nodes
    @ 2015-09-08 18:31   ` Raghavendra K T
      0 siblings, 0 replies; 23+ messages in thread
    From: Raghavendra K T @ 2015-09-08 18:31 UTC (permalink / raw)
      To: benh, paulus, mpe, anton, akpm
      Cc: nacc, gkurz, zhong, grant.likely, nikunj, vdavydov,
    	raghavendra.kt, linuxppc-dev, linux-kernel, linux-mm
    
    Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
    ---
     arch/powerpc/mm/numa.c | 2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)
    
    diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
    index 8b9502a..8d8a541 100644
    --- a/arch/powerpc/mm/numa.c
    +++ b/arch/powerpc/mm/numa.c
    @@ -80,7 +80,7 @@ static void __init setup_node_to_cpumask_map(void)
     		setup_nr_node_ids();
     
     	/* allocate the map */
    -	for (node = 0; node < nr_node_ids; node++)
    +	for_each_node(node)
     		alloc_bootmem_cpumask_var(&node_to_cpumask_map[node]);
     
     	/* cpumask_of_node() will now work */
    -- 
    1.7.11.7
    
    --
    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>
    
    ^ permalink raw reply related	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2015-09-14 13:27 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-08 18:31 [PATCH 0/2] Replace nr_node_ids for loop with for_each_node Raghavendra K T
2015-09-08 18:31 ` Raghavendra K T
2015-09-08 18:31 ` [PATCH 1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru Raghavendra K T
2015-09-08 18:31   ` Raghavendra K T
2015-09-08 18:31   ` Raghavendra K T
2015-09-14  9:00   ` Vladimir Davydov
2015-09-14  9:00     ` Vladimir Davydov
2015-09-14  9:00     ` Vladimir Davydov
2015-09-14 11:39     ` Raghavendra K T
2015-09-14 11:39       ` Raghavendra K T
2015-09-14 11:39       ` Raghavendra K T
2015-09-14 12:04       ` Vladimir Davydov
2015-09-14 12:04         ` Vladimir Davydov
2015-09-14 12:04         ` Vladimir Davydov
2015-09-14 13:05         ` Raghavendra K T
2015-09-14 13:05           ` Raghavendra K T
2015-09-14 13:05           ` Raghavendra K T
2015-09-14 13:27           ` Vladimir Davydov
2015-09-14 13:27             ` Vladimir Davydov
2015-09-14 13:27             ` Vladimir Davydov
2015-09-08 18:31 ` [PATCH 2/2] powerpc:numa Do not allocate bootmem memory for non existing nodes Raghavendra K T
2015-09-08 18:31   ` Raghavendra K T
2015-09-08 18:31   ` Raghavendra K T

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.