[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47fa4cee-8528-7c23-c7de-7be1b65aa2ae@huawei.com>
Date: Tue, 8 Oct 2019 16:38:28 +0800
From: Yunsheng Lin <linyunsheng@...wei.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: Michal Hocko <mhocko@...nel.org>, <catalin.marinas@....com>,
<will@...nel.org>, <mingo@...hat.com>, <bp@...en8.de>,
<rth@...ddle.net>, <ink@...assic.park.msu.ru>,
<mattst88@...il.com>, <benh@...nel.crashing.org>,
<paulus@...ba.org>, <mpe@...erman.id.au>,
<heiko.carstens@...ibm.com>, <gor@...ux.ibm.com>,
<borntraeger@...ibm.com>, <ysato@...rs.sourceforge.jp>,
<dalias@...c.org>, <davem@...emloft.net>, <ralf@...ux-mips.org>,
<paul.burton@...s.com>, <jhogan@...nel.org>,
<jiaxun.yang@...goat.com>, <chenhc@...ote.com>,
<akpm@...ux-foundation.org>, <rppt@...ux.ibm.com>,
<anshuman.khandual@....com>, <tglx@...utronix.de>, <cai@....pw>,
<robin.murphy@....com>, <linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>, <hpa@...or.com>, <x86@...nel.org>,
<dave.hansen@...ux.intel.com>, <luto@...nel.org>,
<len.brown@...el.com>, <axboe@...nel.dk>, <dledford@...hat.com>,
<jeffrey.t.kirsher@...el.com>, <linux-alpha@...r.kernel.org>,
<naveen.n.rao@...ux.vnet.ibm.com>, <mwb@...ux.vnet.ibm.com>,
<linuxppc-dev@...ts.ozlabs.org>, <linux-s390@...r.kernel.org>,
<linux-sh@...r.kernel.org>, <sparclinux@...r.kernel.org>,
<tbogendoerfer@...e.de>, <linux-mips@...r.kernel.org>,
<rafael@...nel.org>, <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware
On 2019/9/25 18:41, Peter Zijlstra wrote:
> On Wed, Sep 25, 2019 at 05:14:20PM +0800, Yunsheng Lin wrote:
>> From the discussion above, It seems making the node_to_cpumask_map()
>> NUMA_NO_NODE aware is the most feasible way to move forwad.
>
> That's still wrong.
Hi, Peter
It seems this has trapped in the dead circle.
>From my understanding, NUMA_NO_NODE which means not node numa preference
is the state to describe the node of virtual device or the physical device
that has equal distance to all cpu.
We can be stricter if the device does have a nearer node, but we can not
deny that a device does not have a node numa preference or node affinity,
which also means the control or data buffer can be allocated at the node where
the process is running.
As you has proposed, making it -2 and have dev_to_node() warn if the device does
have a nearer node and not set by the fw is a way to be stricter.
But I think maybe being stricter is not really relevant to NUMA_NO_NODE, because
we does need a state to describe the device that have equal distance to all node,
even if it is not physically scalable.
Any better suggestion to move this forward?
>
> .
>
Powered by blists - more mailing lists