| Message ID | 5044665C.5020909@cn.fujitsu.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Mon, 03 Sep 2012 16:12:12 +0800 Wen Congyang <wency@cn.fujitsu.com> wrote: > If we don't debug per_cpu maps, the cpu's node is stored in per_cpu variable > numa_node. If node is NUMA_NO_NODE, it means the caller want to clear the > cpu's node. So we should also call set_cpu_numa_node() in this case. The changelog is missing important information. What is the runtime effect of the patch? In other words, please fully describe the runtime effects of the bug which the patch fixed. Please always provide this information. It will help others decide which kernel version(s) should be patched, and will help the maintainers of other kernel trees (especially vendor trees) to work out whether they should backport the fix into their kernels. > --- a/arch/x86/mm/numa.c > +++ b/arch/x86/mm/numa.c > @@ -97,8 +97,7 @@ void __cpuinit numa_set_node(int cpu, int node) > #endif > per_cpu(x86_cpu_to_node_map, cpu) = node; > > - if (node != NUMA_NO_NODE) > - set_cpu_numa_node(cpu, node); > + set_cpu_numa_node(cpu, node); > } > > void __cpuinit numa_clear_node(int cpu) -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
At 09/05/2012 07:11 AM, Andrew Morton Wrote: > On Mon, 03 Sep 2012 16:12:12 +0800 > Wen Congyang <wency@cn.fujitsu.com> wrote: > >> If we don't debug per_cpu maps, the cpu's node is stored in per_cpu variable >> numa_node. If node is NUMA_NO_NODE, it means the caller want to clear the >> cpu's node. So we should also call set_cpu_numa_node() in this case. > > The changelog is missing important information. > > What is the runtime effect of the patch? In other words, please fully > describe the runtime effects of the bug which the patch fixed. > > Please always provide this information. It will help others decide > which kernel version(s) should be patched, and will help the > maintainers of other kernel trees (especially vendor trees) to work out > whether they should backport the fix into their kernels. Sorry for later reply. I found this bug when I try to fix a bug by patch 1/2 (The bug is descriptioned in patch 1/2). Thanks Wen Congyang > >> --- a/arch/x86/mm/numa.c >> +++ b/arch/x86/mm/numa.c >> @@ -97,8 +97,7 @@ void __cpuinit numa_set_node(int cpu, int node) >> #endif >> per_cpu(x86_cpu_to_node_map, cpu) = node; >> >> - if (node != NUMA_NO_NODE) >> - set_cpu_numa_node(cpu, node); >> + set_cpu_numa_node(cpu, node); >> } >> >> void __cpuinit numa_clear_node(int cpu) > > -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c index 2d125be..21d02f0 100644 --- a/arch/x86/mm/numa.c +++ b/arch/x86/mm/numa.c @@ -97,8 +97,7 @@ void __cpuinit numa_set_node(int cpu, int node) #endif per_cpu(x86_cpu_to_node_map, cpu) = node; - if (node != NUMA_NO_NODE) - set_cpu_numa_node(cpu, node); + set_cpu_numa_node(cpu, node); } void __cpuinit numa_clear_node(int cpu)
If we don't debug per_cpu maps, the cpu's node is stored in per_cpu variable numa_node. If node is NUMA_NO_NODE, it means the caller want to clear the cpu's node. So we should also call set_cpu_numa_node() in this case. Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> --- arch/x86/mm/numa.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-)