Thread (7 messages) flat view 7 messages, 3 authors, 2019-09-17

Re: [PATCH v5] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

From: Michal Hocko <mhocko@kernel.org>
Date: 2019-09-17 09:37:04
Also in: linux-alpha, linux-mips, linux-s390, linux-sh, lkml, sparclinux

On Tue 17-09-19 14:20:11, Yunsheng Lin wrote:
On 2019/9/17 13:28, Michael Ellerman wrote:
quoted
Yunsheng Lin [off-list ref] writes:
[...]
quoted
quoted
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.
quoted
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.
-- 
Michal Hocko
SUSE Labs
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help