All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Yunsheng Lin <linyunsheng@huawei.com>
Cc: gregkh@linuxfoundation.org, rafael@kernel.org,
	linux-kernel@vger.kernel.org, peterz@infradead.org,
	mingo@kernel.org, linuxarm@huawei.com
Subject: Re: [PATCH] driver core: ensure a device has valid node id in device_add()
Date: Mon, 9 Sep 2019 20:50:35 +0200	[thread overview]
Message-ID: <20190909185035.GC2063@dhcp22.suse.cz> (raw)
In-Reply-To: <1568009063-77714-1-git-send-email-linyunsheng@huawei.com>

On Mon 09-09-19 14:04:23, Yunsheng Lin wrote:
> Currently a device does not belong to any of the numa nodes
> (dev->numa_node is NUMA_NO_NODE) when the node id is neither
> specified by fw nor by virtual device layer and the device has
> no parent device.
> 
> According to discussion in [1]:

Please do not reference important parts of the justification via a link.
Just quote the relevant part to the changelog. It is just too easy that
external links die - not to mention lkml.org.

> Even if a device's numa node is not specified, the device really
> does belong to a node.

What does this mean?

> This patch sets the device node to node 0 in device_add() if the
> device's node id is not specified and it either has no parent
> device, or the parent device also does not have a valid node id.

Why is node 0 special? I have seen platforms with node 0 missing or
being memory less. The changelog also lacks an actual problem
descripton. Why do we even care about NUMA_NO_NODE? E.g. the page
allocator interprets NUMA_NO_NODE as the closest node with a memory.
And by closest it really means to the CPU which is performing the
allocation.
 
> [1] https://lkml.org/lkml/2019/9/2/466
> 
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> ---
> Changelog RFC -> v1:
> 1. Drop log error message and use a "if" instead of "? :".
> 2. Drop the RFC tag.
> ---
>  drivers/base/core.c  | 10 +++++++---
>  include/linux/numa.h |  2 ++
>  2 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 1669d41..f79ad20 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2107,9 +2107,13 @@ int device_add(struct device *dev)
>  	if (kobj)
>  		dev->kobj.parent = kobj;
>  
> -	/* use parent numa_node */
> -	if (parent && (dev_to_node(dev) == NUMA_NO_NODE))
> -		set_dev_node(dev, dev_to_node(parent));
> +	/* use parent numa_node or default node 0 */
> +	if (!numa_node_valid(dev_to_node(dev))) {
> +		if (parent && numa_node_valid(dev_to_node(parent)))
> +			set_dev_node(dev, dev_to_node(parent));
> +		else
> +			set_dev_node(dev, 0);
> +	}
>  
>  	/* first, register with generic layer. */
>  	/* we require the name to be set before, and pass NULL */
> diff --git a/include/linux/numa.h b/include/linux/numa.h
> index 110b0e5..eccc757 100644
> --- a/include/linux/numa.h
> +++ b/include/linux/numa.h
> @@ -13,4 +13,6 @@
>  
>  #define	NUMA_NO_NODE	(-1)
>  
> +#define numa_node_valid(node)	((unsigned int)(node) < nr_node_ids)
> +
>  #endif /* _LINUX_NUMA_H */
> -- 
> 2.8.1

-- 
Michal Hocko
SUSE Labs

  parent reply	other threads:[~2019-09-09 18:50 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-09  6:04 [PATCH] driver core: ensure a device has valid node id in device_add() Yunsheng Lin
2019-09-09  9:53 ` Greg KH
2019-09-10  6:43   ` Yunsheng Lin
2019-09-10  7:13     ` Michal Hocko
2019-09-10  9:31     ` Greg KH
2019-09-10 10:58       ` Yunsheng Lin
2019-09-10 11:04         ` Michal Hocko
2019-09-10 11:12           ` Greg KH
2019-09-10 12:47             ` Yunsheng Lin
2019-09-10 12:53               ` Michal Hocko
2019-09-11  5:33                 ` Michal Hocko
2019-09-11  6:15                   ` Yunsheng Lin
2019-09-11  6:49                     ` Michal Hocko
2019-09-11  7:22                       ` Yunsheng Lin
2019-09-11  7:34                         ` Michal Hocko
2019-09-11 11:03                           ` Yunsheng Lin
2019-09-11 11:41                             ` Yunsheng Lin
2019-09-11 12:02                               ` Michal Hocko
2019-09-23 15:09                       ` Peter Zijlstra
2019-09-09 18:50 ` Michal Hocko [this message]
2019-09-10  7:08   ` Yunsheng Lin
2019-09-10  7:24     ` Michal Hocko
2019-09-10 10:40       ` Yunsheng Lin
2019-09-10 11:01         ` Michal Hocko

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=20190909185035.GC2063@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=linyunsheng@huawei.com \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rafael@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.