linux-kernel - Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 24 Sep 2019 14:25:00 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Peter Zijlstra <peterz@...radead.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 24-09-19 14:09:43, Peter Zijlstra wrote:
> On Tue, Sep 24, 2019 at 01:54:01PM +0200, Michal Hocko wrote:
> > On Tue 24-09-19 13:23:49, Peter Zijlstra wrote:
> > > On Tue, Sep 24, 2019 at 12:56:22PM +0200, Michal Hocko wrote:
> > [...]
> > > > 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.
> > 
> > What if it doesn't have any numa preference for what ever reason? There
> > is no other way to express that than NUMA_NO_NODE.
> 
> Like I said; how does that physically work? The device needs to be
> somewhere. It _must_ have a preference.
> 
> > Anyway, I am not going to argue more about this because it seems more of
> > a discussion about "HW shouldn't be doing that although the specification
> > allows that" which cannot really have any outcome except of "feels
> > correct/wrong".
> 
> 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.

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.

Anyway, I really do  not feel strongly about that. If you really consider
it a bad idea then I can live with that. This just felt easier and
reasonably consistent to address. Implementing the guessing and fighting
vendors who really do not feel like providing a real affinity sounds
harder and more error prone.
-- 
Michal Hocko
SUSE Labs