All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yunsheng Lin <linyunsheng@huawei.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: <rafael@kernel.org>, <linux-kernel@vger.kernel.org>,
	<peterz@infradead.org>, <mingo@kernel.org>, <mhocko@kernel.org>,
	<linuxarm@huawei.com>
Subject: Re: [PATCH] driver core: ensure a device has valid node id in device_add()
Date: Tue, 10 Sep 2019 14:43:32 +0800	[thread overview]
Message-ID: <9598b359-ab96-7d61-687a-917bee7a5cd9@huawei.com> (raw)
In-Reply-To: <20190909095347.GB6314@kroah.com>

On 2019/9/9 17:53, Greg KH wrote:
> On Mon, Sep 09, 2019 at 02:04:23PM +0800, 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.
> 
> Is this really a problem?

Not really.
Someone need to guess the node id when it is not specified, right?
This patch chooses to guess the node id in the driver core.

> 
>> According to discussion in [1]:
>> Even if a device's numa node is not specified, the device really
>> does belong to a node.
> 
> But as we do not know the node, can we cause more harm by randomly
> picking one (i.e. putting it all in node 0)?
If we do not pick node 0 for device with invalid node, then caller need
to check the node id and pick one, and currently different callers
does a different checking:

1) some does " < 0" check;
2) some does "== NUMA_NO_NODE" check;
3) some does ">= MAX_NUMNODES" check;
4) some does "< 0 || >= MAX_NUMNODES || !node_online(node)" check.

and caller of dev_to_node() may pick one node based on below if the
dev_to_node() return a invalid node based on above checking:
1) based on numa_mem_id().
2) pick a random one like in workqueue_select_cpu_near().

If we pick node 0 for device with invalid node in device_add(), we
may avoid the above different checking and picking for caller, but we
may lose some caller context info, for example, user may use node of the
cpu on which the process is using the device to allocate the resource
close to the process, or user may pick a random one if they know what
they are doing.

It seems there is trade off here, as I can see, we can guess and pick the
node at different stage when it is not specified.
1. guess and pick node 0 at device_add(), it has the advantage of ensure
   all devices will have a valid node at very begin of device creation,
   so the user does not have to check and guess one, but user might lose
   the opportunity to do their own guessing and picking.

2. Maybe provide a dev_to_valid_node() to always return a valid node id,
   for example return numa_mem_id() if dev->numa_node is not valid.
   User know what they are doing can still use dev_to_node().

3. Caller of dev_to_node() do their own checking and picking, which
   might lead to adding more different and reduplicate checking as above.


  reply	other threads:[~2019-09-10  6:44 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 [this message]
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
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=9598b359-ab96-7d61-687a-917bee7a5cd9@huawei.com \
    --to=linyunsheng@huawei.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=mhocko@kernel.org \
    --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.