linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Wei Yang <weiyang@linux.vnet.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Wei Yang <weiyang@linux.vnet.ibm.com>, tj@kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm/page: refine the calculation of highest possible node id
Date: Fri, 10 Jul 2015 16:27:51 +0800	[thread overview]
Message-ID: <20150710082751.GA21679@richard> (raw)
In-Reply-To: <20150710003555.4398c8ad.akpm@linux-foundation.org>

On Fri, Jul 10, 2015 at 12:35:55AM -0700, Andrew Morton wrote:
>On Fri, 10 Jul 2015 14:26:21 +0800 Wei Yang <weiyang@linux.vnet.ibm.com> wrote:
>
>> nr_node_ids records the highest possible node id, which is calculated by
>> scanning the bitmap node_states[N_POSSIBLE]. Current implementation scan
>> the bitmap from the beginning, which will scan the whole bitmap.
>> 
>> This patch reverse the order by scanning from the end. By doing so, this
>> will save some time whose worst case is the best case of current
>> implementation.
>
>It hardly matters - setup_nr_node_ids() is called a single time, at boot.

Hi, Andrew,

Glad to receive your comment :-)

Yes, the hardly matters on the performance side, while scanning from the end is
a better way to me. Hope you like it.

>
>> --- a/include/linux/nodemask.h
>> +++ b/include/linux/nodemask.h
>> @@ -253,6 +253,12 @@ static inline int __first_node(const nodemask_t *srcp)
>>  	return min_t(int, MAX_NUMNODES, find_first_bit(srcp->bits, MAX_NUMNODES));
>>  }
>>  
>> +#define last_node(src) __last_node(&(src))
>> +static inline int __last_node(const nodemask_t *srcp)
>> +{
>> +	return min_t(int, MAX_NUMNODES, find_last_bit(srcp->bits, MAX_NUMNODES));
>> +}
>
>hm.  Why isn't this just
>
>	return find_last_bit(srcp->bits, MAX_NUMNODES);
>
>?

I found this comment in the code:

/* FIXME: better would be to fix all architectures to never return
          > MAX_NUMNODES, then the silly min_ts could be dropped. */

While I didn't find the original commit for this change, so not dear to change
the related code format.

>
>> @@ -360,10 +366,20 @@ static inline void __nodes_fold(nodemask_t *dstp, const nodemask_t *origp,
>>  	for ((node) = first_node(mask);			\
>>  		(node) < MAX_NUMNODES;			\
>>  		(node) = next_node((node), (mask)))
>> +
>> +static inline int highest_node_id(const nodemask_t possible)
>> +{
>> +	return last_node(possible);
>> +}
>
>`possible' isn't a good identifier.  This function doesn't *know* that
>its caller passed node_possible_map.  Another caller could pass some
>other nodemask.
>

Agree. I would change it.

>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -5453,8 +5453,7 @@ void __init setup_nr_node_ids(void)
>>  	unsigned int node;
>>  	unsigned int highest = 0;
>
>The "= 0" can now be removed.
>
>> -	for_each_node_mask(node, node_possible_map)
>> -		highest = node;
>> +	highest = highest_node_id(node_possible_map);
>
>I suspect we can just open-code a find_last_bit() here and all the
>infrastructure isn't needed.
>

This is reasonable. If so, the code would be more clear.

>>  	nr_node_ids = highest + 1;
>>  }
>
>
>And I suspect the "#if MAX_NUMNODES > 1" around setup_nr_node_ids() can
>be removed.  Because if MAX_NUMNODES is ever <= 1 when
>CONFIG_HAVE_MEMBLOCK_NODE_MAP=y, the kernel won't compile.

Hmm... for this one, I am not sure.

#define MAX_NUMNODES    (1 << NODES_SHIFT)
#define NODES_SHIFT     CONFIG_NODES_SHIFT

CONFIG_NODES_SHIFT depends on CONFIG_NEED_MULTIPLE_NODES, which depends on
CONFIG_DISCONTIGMEM or CONFIG_NUMA.

And I grep the kernel tree, not see other configuration would depend on
HAVE_MEMBLOCK_NODE_MAP.

So I am don't get a clear clue for this suspection.

-- 
Richard Yang
Help you, Help me

--
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>

  reply	other threads:[~2015-07-10  8:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-10  6:26 [PATCH] mm/page: refine the calculation of highest possible node id Wei Yang
2015-07-10  7:35 ` Andrew Morton
2015-07-10  8:27   ` Wei Yang [this message]
2015-07-11  3:08   ` [PATCH V2] " Wei Yang
2015-07-11  4:17     ` [PATCH V3] " Wei Yang
2015-07-16  0:16       ` David Rientjes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150710082751.GA21679@richard \
    --to=weiyang@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).