[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190924124325.GQ2349@hirez.programming.kicks-ass.net>
Date: Tue, 24 Sep 2019 14:43:25 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Michal Hocko <mhocko@...nel.org>
Cc: Yunsheng Lin <linyunsheng@...wei.com>, 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 Tue, Sep 24, 2019 at 02:25:00PM +0200, Michal Hocko wrote:
> On Tue 24-09-19 14:09:43, Peter Zijlstra wrote:
> > We can push back and say we don't respect the specification because it
> > is batshit insane ;-)
>
> Here is my fingers crossed.
>
> [...]
>
> > Now granted; there's a number of virtual devices that really don't have
> > a node affinity, but then, those are not hurt by forcing them onto a
> > random node, they really don't do anything. Like:
>
> Do you really consider a random node a better fix than simply living
> with a more robust NUMA_NO_NODE which tells the actual state? Page
> allocator would effectivelly use the local node in that case. Any code
> using the cpumask will know that any of the online cpus are usable.
For the pmu devices? Yes, those 'devices' aren't actually used for
anything other than sysfs entries.
Nothing else uses the struct device.
> Compare that to a wild guess that might be easily wrong and have subtle
> side effects which are really hard to debug. You will only see a higher
> utilization on a specific node. Good luck with a bug report like that.
We'd have the FW_BUG in the dmesg, which should be a big fat clue.
Powered by blists - more mailing lists