linux-kernel - Re: [PATCH v5] 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] [day] [month] [year] [list]

Message-ID: <7fe82a6a-2183-3d9d-2740-0d4fe123b813@huawei.com>
Date:   Tue, 17 Sep 2019 19:36:39 +0800
From:   Yunsheng Lin <linyunsheng@...wei.com>
To:     Michal Hocko <mhocko@...nel.org>
CC:     Michael Ellerman <mpe@...erman.id.au>, <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>, <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>,
        <peterz@...radead.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 v5] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On 2019/9/17 18:08, Michal Hocko wrote:
> On Tue 17-09-19 17:53:57, Yunsheng Lin wrote:
>> On 2019/9/17 17:36, Michal Hocko wrote:
>>> On Tue 17-09-19 14:20:11, Yunsheng Lin wrote:
>>>> On 2019/9/17 13:28, Michael Ellerman wrote:
>>>>> Yunsheng Lin <linyunsheng@...wei.com> writes:
>>> [...]
>>>>>> But we cannot really copy the page allocator logic. Simply because the
>>>>>> page allocator doesn't enforce the near node affinity. It just picks it
>>>>>> up as a preferred node but then it is free to fallback to any other numa
>>>>>> node. This is not the case here and node_to_cpumask_map will only restrict
>>>>>> to the particular node's cpus which would have really non deterministic
>>>>>> behavior depending on where the code is executed. So in fact we really
>>>>>> want to return cpu_online_mask for NUMA_NO_NODE.
>>>>>>
>>>>>> Some arches were already NUMA_NO_NODE aware, but they return cpu_all_mask,
>>>>>> which should be identical with cpu_online_mask when those arches do not
>>>>>> support cpu hotplug, this patch also changes them to return cpu_online_mask
>>>>>> in order to be consistent and use NUMA_NO_NODE instead of "-1".
>>>>>
>>>>> Except some of those arches *do* support CPU hotplug, powerpc and sparc
>>>>> at least. So switching from cpu_all_mask to cpu_online_mask is a
>>>>> meaningful change.
>>>>
>>>> Yes, thanks for pointing out.
>>>>
>>>>>
>>>>> That doesn't mean it's wrong, but you need to explain why it's the right
>>>>> change.
>>>>
>>>> How about adding the below to the commit log:
>>>> Even if some of the arches do support CPU hotplug, it does not make sense
>>>> to return the cpu that has been hotplugged.
>>>>
>>>> Any suggestion?
>>>
>>> Again, for the third time, I believe. Make it a separate patch please.
>>> There is absolutely no reason to conflate those two things.
>>
>> Ok, thanks.
>> Will make the cpu_all_mask -> cpu_online_mask change a separate patch.
> 
> Thanks. This really needs per arch maintainer to check closely.
> 
>> Also, do you think it is better to resend this as individual patches for each arch
>> or have all these changes in a single patch? I am not sure which is the common
>> practice for a multi-arches changes like this.
> 
> It really depends on arch maintainers. Both approaches have some pros
> and cons. A single patch is more compact and and parts are not going to
> get lost in noise. They might generate some conflicts with parallel
> changes. I suspect a conflict risk is quite low in this code considering
> from a recent activity. A follow up arch specific patch would have to be
> routed via Andrew as well.
> 
> If Andrew is ok routing it through his tree and none of the arch
> maintainers is opposed then I would go with a single patch.

Ok, I will try a single patch for NUMA_NO_NODE aware change first.
"cpu_all_mask -> cpu_online_mask" change seems a little controversial,
and may need deeper investigation.


>