All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: linux-kernel@vger.kernel.org, tj@kernel.org, mingo@redhat.com,
	x86@kernel.org, rjw@rjwysocki.net, hpa@zytor.com,
	linux-acpi@vger.kernel.org, laijs@cn.fujitsu.com,
	isimatu.yasuaki@jp.fujitsu.com, tangchen@cn.fujitsu.com,
	izumi.taku@jp.fujitsu.com
Subject: Re: [RESEND RFC PATCH 2/2] gfp: use the best near online node if the target node is offline
Date: Mon, 27 Apr 2015 18:44:48 +0900	[thread overview]
Message-ID: <553E0510.9040001@jp.fujitsu.com> (raw)
In-Reply-To: <20150424130153.f7b494f1533529651b2696c6@linux-foundation.org>

On 2015/04/25 5:01, Andrew Morton wrote:
> On Fri, 24 Apr 2015 17:58:33 +0800 Gu Zheng <guz.fnst@cn.fujitsu.com> wrote:
>
>> Since the change to the cpu <--> mapping (map the cpu to the physical
>> node for all possible at the boot), the node of cpu may be not present,
>> so we use the best near online node if the node is not present in the low
>> level allocation APIs.
>>
>> ...
>>
>> --- a/include/linux/gfp.h
>> +++ b/include/linux/gfp.h
>> @@ -298,9 +298,31 @@ __alloc_pages(gfp_t gfp_mask, unsigned int order,
>>   	return __alloc_pages_nodemask(gfp_mask, order, zonelist, NULL);
>>   }
>>
>> +static int find_near_online_node(int node)
>> +{
>> +	int n, val;
>> +	int min_val = INT_MAX;
>> +	int best_node = -1;
>> +
>> +	for_each_online_node(n) {
>> +		val = node_distance(node, n);
>> +
>> +		if (val < min_val) {
>> +			min_val = val;
>> +			best_node = n;
>> +		}
>> +	}
>> +
>> +	return best_node;
>> +}
>
> This should be `inline' if it's in a header file.
>
> But it is far too large to be inlined anyway - please move it to a .c file.
>
> And please document it.  A critical thing to describe is how we
> determine whether a node is "near".  There are presumably multiple ways
> in which we could decide that a node is "near" (number of hops, minimum
> latency, ...).  Which one did you choose, and why?
>
>>   static inline struct page *alloc_pages_node(int nid, gfp_t gfp_mask,
>>   						unsigned int order)
>>   {
>> +	/* Offline node, use the best near online node */
>> +	if (!node_online(nid))
>> +		nid = find_near_online_node(nid);
>> +
>>   	/* Unknown node is current node */
>>   	if (nid < 0)
>>   		nid = numa_node_id();
>> @@ -311,7 +333,11 @@ static inline struct page *alloc_pages_node(int nid, gfp_t gfp_mask,
>>   static inline struct page *alloc_pages_exact_node(int nid, gfp_t gfp_mask,
>>   						unsigned int order)
>>   {
>> -	VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES || !node_online(nid));
>> +	/* Offline node, use the best near online node */
>> +	if (!node_online(nid))
>> +		nid = find_near_online_node(nid);

In above VM_BUG_ON(), !node_online(nid) is the bug.

>> +
>> +	VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
>>
>>   	return __alloc_pages(gfp_mask, order, node_zonelist(nid, gfp_mask));
>>   }
>
> Ouch.  These functions are called very frequently, and adding overhead
> to them is a big deal.  And the patch even adds overhead to non-x86
> architectures which don't benefit from it!
>
> Is there no way this problem can be fixed somewhere else?  Preferably
> by fixing things up at hotplug time.

I agree. the results should be cached. If necessary, in per-cpu line.


Thanks,
-Kame

WARNING: multiple messages have this Message-ID (diff)
From: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: <linux-kernel@vger.kernel.org>, <tj@kernel.org>,
	<mingo@redhat.com>, <x86@kernel.org>, <rjw@rjwysocki.net>,
	<hpa@zytor.com>, <linux-acpi@vger.kernel.org>,
	<laijs@cn.fujitsu.com>, <isimatu.yasuaki@jp.fujitsu.com>,
	<tangchen@cn.fujitsu.com>, <izumi.taku@jp.fujitsu.com>
Subject: Re: [RESEND RFC PATCH 2/2] gfp: use the best near online node if the target node is offline
Date: Mon, 27 Apr 2015 18:44:48 +0900	[thread overview]
Message-ID: <553E0510.9040001@jp.fujitsu.com> (raw)
In-Reply-To: <20150424130153.f7b494f1533529651b2696c6@linux-foundation.org>

On 2015/04/25 5:01, Andrew Morton wrote:
> On Fri, 24 Apr 2015 17:58:33 +0800 Gu Zheng <guz.fnst@cn.fujitsu.com> wrote:
>
>> Since the change to the cpu <--> mapping (map the cpu to the physical
>> node for all possible at the boot), the node of cpu may be not present,
>> so we use the best near online node if the node is not present in the low
>> level allocation APIs.
>>
>> ...
>>
>> --- a/include/linux/gfp.h
>> +++ b/include/linux/gfp.h
>> @@ -298,9 +298,31 @@ __alloc_pages(gfp_t gfp_mask, unsigned int order,
>>   	return __alloc_pages_nodemask(gfp_mask, order, zonelist, NULL);
>>   }
>>
>> +static int find_near_online_node(int node)
>> +{
>> +	int n, val;
>> +	int min_val = INT_MAX;
>> +	int best_node = -1;
>> +
>> +	for_each_online_node(n) {
>> +		val = node_distance(node, n);
>> +
>> +		if (val < min_val) {
>> +			min_val = val;
>> +			best_node = n;
>> +		}
>> +	}
>> +
>> +	return best_node;
>> +}
>
> This should be `inline' if it's in a header file.
>
> But it is far too large to be inlined anyway - please move it to a .c file.
>
> And please document it.  A critical thing to describe is how we
> determine whether a node is "near".  There are presumably multiple ways
> in which we could decide that a node is "near" (number of hops, minimum
> latency, ...).  Which one did you choose, and why?
>
>>   static inline struct page *alloc_pages_node(int nid, gfp_t gfp_mask,
>>   						unsigned int order)
>>   {
>> +	/* Offline node, use the best near online node */
>> +	if (!node_online(nid))
>> +		nid = find_near_online_node(nid);
>> +
>>   	/* Unknown node is current node */
>>   	if (nid < 0)
>>   		nid = numa_node_id();
>> @@ -311,7 +333,11 @@ static inline struct page *alloc_pages_node(int nid, gfp_t gfp_mask,
>>   static inline struct page *alloc_pages_exact_node(int nid, gfp_t gfp_mask,
>>   						unsigned int order)
>>   {
>> -	VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES || !node_online(nid));
>> +	/* Offline node, use the best near online node */
>> +	if (!node_online(nid))
>> +		nid = find_near_online_node(nid);

In above VM_BUG_ON(), !node_online(nid) is the bug.

>> +
>> +	VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
>>
>>   	return __alloc_pages(gfp_mask, order, node_zonelist(nid, gfp_mask));
>>   }
>
> Ouch.  These functions are called very frequently, and adding overhead
> to them is a big deal.  And the patch even adds overhead to non-x86
> architectures which don't benefit from it!
>
> Is there no way this problem can be fixed somewhere else?  Preferably
> by fixing things up at hotplug time.

I agree. the results should be cached. If necessary, in per-cpu line.


Thanks,
-Kame



  reply	other threads:[~2015-04-27  9:44 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-24  9:58 [RESEND RFC PATCH 1/2] x86/cpu hotplug: make apicid <--> cpuid mapping persistent Gu Zheng
2015-04-24  9:58 ` Gu Zheng
2015-04-24  9:58 ` [RESEND RFC PATCH 2/2] gfp: use the best near online node if the target node is offline Gu Zheng
2015-04-24  9:58   ` Gu Zheng
2015-04-24 20:01   ` Andrew Morton
2015-04-24 20:01     ` Andrew Morton
2015-04-27  9:44     ` Kamezawa Hiroyuki [this message]
2015-04-27  9:44       ` Kamezawa Hiroyuki
2015-04-27 10:26       ` Gu Zheng
2015-04-27 10:26         ` Gu Zheng
2015-04-27 10:19     ` Gu Zheng
2015-04-27 10:19       ` Gu Zheng
2015-04-24 14:45 ` [RESEND RFC PATCH 1/2] x86/cpu hotplug: make apicid <--> cpuid mapping persistent Rafael J. Wysocki
2015-04-25 10:14   ` Hanjun Guo
2015-04-25 10:14     ` Hanjun Guo
2015-04-27 10:28     ` Gu Zheng
2015-04-27 10:28       ` Gu Zheng

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=553E0510.9040001@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=guz.fnst@cn.fujitsu.com \
    --cc=hpa@zytor.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rjw@rjwysocki.net \
    --cc=tangchen@cn.fujitsu.com \
    --cc=tj@kernel.org \
    --cc=x86@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 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.