From: Peter Zijlstra <peterz@infradead.org> To: Michal Hocko <mhocko@kernel.org> Cc: dalias@libc.org, linux-sh@vger.kernel.org, catalin.marinas@arm.com, dave.hansen@linux.intel.com, heiko.carstens@de.ibm.com, jiaxun.yang@flygoat.com, linux-mips@vger.kernel.org, mwb@linux.vnet.ibm.com, paulus@samba.org, hpa@zytor.com, sparclinux@vger.kernel.org, chenhc@lemote.com, will@kernel.org, cai@lca.pw, linux-s390@vger.kernel.org, ysato@users.sourceforge.jp, x86@kernel.org, Yunsheng Lin <linyunsheng@huawei.com>, rppt@linux.ibm.com, borntraeger@de.ibm.com, dledford@redhat.com, mingo@redhat.com, jeffrey.t.kirsher@intel.com, jhogan@kernel.org, mattst88@gmail.com, len.brown@intel.com, gor@linux.ibm.com, anshuman.khandual@arm.com, gregkh@linuxfoundation.org, bp@alien8.de, luto@kernel.org, tglx@linutronix.de, naveen.n.rao@linux.vnet.ibm.com, linux-arm-kernel@lists.infradead.org, rth@twiddle.net, axboe@kernel.dk, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, ralf@linux-mips.org, tbogendoerfer@suse.de, paul.burton@mips.com, linux-alpha@vger.kernel.org, rafael@kernel.org, ink@jurassic.park.msu.ru, akpm@linux-foundation.org, robin.murphy@arm.com, davem@davemloft.net Subject: Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware Date: Tue, 24 Sep 2019 13:23:49 +0200 Message-ID: <20190924112349.GJ2332@hirez.programming.kicks-ass.net> (raw) In-Reply-To: <20190924105622.GH23050@dhcp22.suse.cz> On Tue, Sep 24, 2019 at 12:56:22PM +0200, Michal Hocko wrote: > On Tue 24-09-19 11:17:14, Peter Zijlstra wrote: > > On Tue, Sep 24, 2019 at 09:47:51AM +0200, Michal Hocko wrote: > > > On Mon 23-09-19 22:34:10, Peter Zijlstra wrote: > > > > On Mon, Sep 23, 2019 at 06:52:35PM +0200, Michal Hocko wrote: > > > [...] > > > > > I even the > > > > > ACPI standard is considering this optional. Yunsheng Lin has referred to > > > > > the specific part of the standard in one of the earlier discussions. > > > > > Trying to guess the node affinity is worse than providing all CPUs IMHO. > > > > > > > > I'm saying the ACPI standard is wrong. > > > > > > Even if you were right on this the reality is that a HW is likely to > > > follow that standard and we cannot rule out NUMA_NO_NODE being > > > specified. As of now we would access beyond the defined array and that > > > is clearly a bug. > > > > Right, because the device node is wrong, so we fix _that_! > > > > > Let's assume that this is really a bug for a moment. What are you going > > > to do about that? BUG_ON? I do not really see any solution besides to either > > > provide something sensible or BUG_ON. If you are worried about a > > > conditional then this should be pretty easy to solve by starting the > > > array at -1 index and associate it with the online cpu mask. > > > > The same thing I proposed earlier; force the device node to 0 (or any > > other convenient random valid value) and issue a FW_BUG message to the > > console. > > Why would you "fix" anything and how do you know that node 0 is the > right choice? I have seen setups with node 0 without any memory and > similar unexpected things. We don't know 0 is right; but we know 'unkown' is wrong, so we FW_BUG and pick _something_. > To be honest I really fail to see why to object to a simple semantic > that NUMA_NO_NODE imply all usable cpus. Could you explain that please? Because it feels wrong. The device needs to be _somewhere_. It simply cannot be node-less.
next prev parent reply index Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-17 12:48 Yunsheng Lin 2019-09-21 22:38 ` Paul Burton 2019-09-23 2:31 ` Yunsheng Lin 2019-09-23 15:15 ` Peter Zijlstra 2019-09-23 15:28 ` Michal Hocko 2019-09-23 15:48 ` Peter Zijlstra 2019-09-23 16:52 ` Michal Hocko 2019-09-23 20:34 ` Peter Zijlstra 2019-09-24 1:29 ` Yunsheng Lin 2019-09-24 9:25 ` Peter Zijlstra 2019-09-24 11:07 ` Yunsheng Lin 2019-09-24 11:28 ` Peter Zijlstra 2019-09-24 11:44 ` Yunsheng Lin 2019-09-24 11:58 ` Peter Zijlstra 2019-09-24 12:09 ` Yunsheng Lin 2019-09-24 7:47 ` Michal Hocko 2019-09-24 9:17 ` Peter Zijlstra 2019-09-24 10:56 ` Michal Hocko 2019-09-24 11:23 ` Peter Zijlstra [this message] 2019-09-24 11:54 ` Michal Hocko 2019-09-24 12:09 ` Peter Zijlstra 2019-09-24 12:25 ` Michal Hocko 2019-09-24 12:43 ` Peter Zijlstra 2019-09-24 12:59 ` Peter Zijlstra 2019-09-24 13:19 ` Michal Hocko 2019-09-25 9:14 ` Yunsheng Lin 2019-09-25 10:41 ` Peter Zijlstra 2019-10-08 8:38 ` Yunsheng Lin 2019-10-09 12:25 ` Robin Murphy 2019-10-10 6:07 ` Yunsheng Lin 2019-10-10 7:32 ` Michal Hocko 2019-10-11 3:27 ` Yunsheng Lin 2019-10-11 11:15 ` Peter Zijlstra 2019-10-12 6:17 ` Yunsheng Lin 2019-10-12 7:40 ` Greg KH 2019-10-12 9:47 ` Yunsheng Lin 2019-10-12 10:40 ` Greg KH 2019-10-12 10:47 ` Greg KH 2019-10-14 8:00 ` Yunsheng Lin 2019-10-14 9:25 ` Greg KH 2019-10-14 9:49 ` Peter Zijlstra 2019-10-14 10:04 ` Greg KH 2019-10-15 10:40 ` Yunsheng Lin 2019-10-15 16:58 ` Greg KH 2019-10-16 12:07 ` Yunsheng Lin 2019-10-28 9:20 ` Yunsheng Lin 2019-10-29 8:53 ` Michal Hocko 2019-10-30 1:58 ` Yunsheng Lin 2019-10-10 8:56 ` Peter Zijlstra 2019-09-25 10:40 ` Peter Zijlstra 2019-09-25 13:25 ` Michal Hocko 2019-09-25 16:31 ` Peter Zijlstra 2019-09-25 21:45 ` Peter Zijlstra 2019-09-26 9:05 ` Peter Zijlstra 2019-09-26 12:10 ` Peter Zijlstra 2019-09-26 11:45 ` Geert Uytterhoeven 2019-09-26 12:24 ` Peter Zijlstra
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=20190924112349.GJ2332@hirez.programming.kicks-ass.net \ --to=peterz@infradead.org \ --cc=akpm@linux-foundation.org \ --cc=anshuman.khandual@arm.com \ --cc=axboe@kernel.dk \ --cc=borntraeger@de.ibm.com \ --cc=bp@alien8.de \ --cc=cai@lca.pw \ --cc=catalin.marinas@arm.com \ --cc=chenhc@lemote.com \ --cc=dalias@libc.org \ --cc=dave.hansen@linux.intel.com \ --cc=davem@davemloft.net \ --cc=dledford@redhat.com \ --cc=gor@linux.ibm.com \ --cc=gregkh@linuxfoundation.org \ --cc=heiko.carstens@de.ibm.com \ --cc=hpa@zytor.com \ --cc=ink@jurassic.park.msu.ru \ --cc=jeffrey.t.kirsher@intel.com \ --cc=jhogan@kernel.org \ --cc=jiaxun.yang@flygoat.com \ --cc=len.brown@intel.com \ --cc=linux-alpha@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mips@vger.kernel.org \ --cc=linux-s390@vger.kernel.org \ --cc=linux-sh@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=linyunsheng@huawei.com \ --cc=luto@kernel.org \ --cc=mattst88@gmail.com \ --cc=mhocko@kernel.org \ --cc=mingo@redhat.com \ --cc=mwb@linux.vnet.ibm.com \ --cc=naveen.n.rao@linux.vnet.ibm.com \ --cc=paul.burton@mips.com \ --cc=paulus@samba.org \ --cc=rafael@kernel.org \ --cc=ralf@linux-mips.org \ --cc=robin.murphy@arm.com \ --cc=rppt@linux.ibm.com \ --cc=rth@twiddle.net \ --cc=sparclinux@vger.kernel.org \ --cc=tbogendoerfer@suse.de \ --cc=tglx@linutronix.de \ --cc=will@kernel.org \ --cc=x86@kernel.org \ --cc=ysato@users.sourceforge.jp \ /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
LinuxPPC-Dev Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linuxppc-dev/0 linuxppc-dev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linuxppc-dev linuxppc-dev/ https://lore.kernel.org/linuxppc-dev \ linuxppc-dev@lists.ozlabs.org linuxppc-dev@ozlabs.org public-inbox-index linuxppc-dev Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.ozlabs.lists.linuxppc-dev AGPL code for this site: git clone https://public-inbox.org/public-inbox.git