Hi David,
Thanks for reviewing this patch. :)
On 10/09/2012 04:34 PM, Wen Congyang wrote:
At 10/09/2012 02:21 PM, David Rientjes Wrote:
On Mon, 8 Oct 2012, Tang Chen wrote:
+ /* If the cpu has been offlined, its nid was set to -1. */
+ if (nid != -1) {
NUMA_NO_NODE.
Yes, NUMA_NO_NODE is better. I'll improve it, thanks. :)
Eek, the nid shouldn't be -1 yet, though, for cpu hotplug since this
should be called at CPU_DYING level and migrate_tasks() still sees a valid
cpu.
As Wen said below, nid is now set to -1 when cpu is hotremoved.
I reproduce this problem in this situation:
all cpus are online, and hot remove a system board directorily, without
offlining any cpu.
As a result, the removed cpu's nid is set to -1, and this causes
problems.
the cpu's node is set when the cpu is hotpluged(not online), and it will
be cleared when the cpu is hotremoved(This patch is in akpm tree):
https://lkml.org/lkml/2012/9/3/39
I guess the task is in sleep state when the cpu is offlined, and it doesn't
be migrated to another cpu.
Thanks
Wen Congyang
On x86, cpumask_of_node() is always guaranteed to return a valid cpumask
after boot so presumably this is a problem in some non-x86 arch code and
isn't actually a sched problem.
BTW, my box is x86. I think for the reason I said above,
cpumask_of_node() will no longer guaranteed anything even if on x86.
Thanks. :)
+ nodemask = cpumask_of_node(nid);
+
+ /* Look for allowed, online CPU in same node. */
+ for_each_cpu(dest_cpu, nodemask) {
+ if (!cpu_online(dest_cpu))
+ continue;
+ if (!cpu_active(dest_cpu))
+ continue;
+ if (cpumask_test_cpu(dest_cpu, tsk_cpus_allowed(p)))
+ return dest_cpu;
+ }
}
for (;;) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-numa" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
