* [Patch] x86 : set numa_nodes_parsed at acpi_numa_memory_affinity_init
@ 2012-05-29 7:45 Yasuaki Ishimatsu
2012-05-31 11:25 ` KOSAKI Motohiro
2012-05-31 20:37 ` David Rientjes
0 siblings, 2 replies; 6+ messages in thread
From: Yasuaki Ishimatsu @ 2012-05-29 7:45 UTC (permalink / raw)
To: hpa, mingo, tglx, x86, linux-kernel
When hot-adding a CPU into my system, the system showed following message
since node_to_cpumask_map[2] was not allocated memory.
Booting Node 2 Processor 32 APIC 0xc0
node_to_cpumask_map[2] NULL
Pid: 0, comm: swapper/32 Tainted: G A 3.3.5-acd #21
Call Trace:
[<ffffffff81048845>] debug_cpumask_set_cpu+0x155/0x160
[<ffffffff8105e28a>] ? add_timer_on+0xaa/0x120
[<ffffffff8150665f>] numa_add_cpu+0x1e/0x22
[<ffffffff815020bb>] identify_cpu+0x1df/0x1e4
[<ffffffff815020d6>] identify_econdary_cpu+0x16/0x1d
[<ffffffff81504614>] smp_store_cpu_info+0x3c/0x3e
[<ffffffff81505263>] smp_callin+0x139/0x1be
[<ffffffff815052fb>] start_secondary+0x13/0xeb
In my investigation, the root cause is that the bit of node 2 was not set at
numa_nodes_parsed since hot-added cpu was not written in ACPI SRAT Table.
But hot-added memory which is same PXM as the cpu is written in here.
ACPI Spec Rev 5.0 says about ACPI SRAT talbe as follows:
This optional table provides information that allows OSPM to associate
processors and memory ranges, including ranges of memory provided by
hot-added memory devices, with system localities / proximity domains
and clock domains.
So I think the ACPI SRAT Table is not wrong. Thus numa_nodes_parsed should be set
by not only acpi_numa_processor_affinity_init / acpi_numa_x2apic_affinity_init
but also acpi_numa_memory_affinity_init for the case.
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
---
arch/x86/mm/srat.c | 2 ++
1 file changed, 2 insertions(+)
Index: linux-3.4/arch/x86/mm/srat.c
===================================================================
--- linux-3.4.orig/arch/x86/mm/srat.c 2012-05-21 07:29:13.000000000 +0900
+++ linux-3.4/arch/x86/mm/srat.c 2012-05-29 05:28:27.353916902 +0900
@@ -176,6 +176,8 @@ acpi_numa_memory_affinity_init(struct ac
return;
}
+ node_set(node, numa_nodes_parsed);
+
printk(KERN_INFO "SRAT: Node %u PXM %u %Lx-%Lx\n", node, pxm,
start, end);
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Patch] x86 : set numa_nodes_parsed at acpi_numa_memory_affinity_init
2012-05-29 7:45 [Patch] x86 : set numa_nodes_parsed at acpi_numa_memory_affinity_init Yasuaki Ishimatsu
@ 2012-05-31 11:25 ` KOSAKI Motohiro
2012-05-31 12:39 ` Jiang Liu
2012-06-01 11:08 ` Yasuaki Ishimatsu
2012-05-31 20:37 ` David Rientjes
1 sibling, 2 replies; 6+ messages in thread
From: KOSAKI Motohiro @ 2012-05-31 11:25 UTC (permalink / raw)
To: Yasuaki Ishimatsu; +Cc: hpa, mingo, tglx, x86, linux-kernel, kosaki.motohiro
Hi Ishimatsu-san,
(5/29/12 3:45 AM), Yasuaki Ishimatsu wrote:
> When hot-adding a CPU into my system, the system showed following message
> since node_to_cpumask_map[2] was not allocated memory.
>
> Booting Node 2 Processor 32 APIC 0xc0
> node_to_cpumask_map[2] NULL
> Pid: 0, comm: swapper/32 Tainted: G A 3.3.5-acd #21
> Call Trace:
> [<ffffffff81048845>] debug_cpumask_set_cpu+0x155/0x160
> [<ffffffff8105e28a>] ? add_timer_on+0xaa/0x120
> [<ffffffff8150665f>] numa_add_cpu+0x1e/0x22
> [<ffffffff815020bb>] identify_cpu+0x1df/0x1e4
> [<ffffffff815020d6>] identify_econdary_cpu+0x16/0x1d
> [<ffffffff81504614>] smp_store_cpu_info+0x3c/0x3e
> [<ffffffff81505263>] smp_callin+0x139/0x1be
> [<ffffffff815052fb>] start_secondary+0x13/0xeb
>
> In my investigation, the root cause is that the bit of node 2 was not set at
> numa_nodes_parsed since hot-added cpu was not written in ACPI SRAT Table.
> But hot-added memory which is same PXM as the cpu is written in here.
I don't understand this explanation. If cpu is not written in srat table,
it is firmware bug. isn't it? srat table should describe all possible cpus.
Why doesn't your system describe cpu info in acpi table?
>
> ACPI Spec Rev 5.0 says about ACPI SRAT talbe as follows:
> This optional table provides information that allows OSPM to associate
> processors and memory ranges, including ranges of memory provided by
> hot-added memory devices, with system localities / proximity domains
> and clock domains.
>
> So I think the ACPI SRAT Table is not wrong. Thus numa_nodes_parsed should be set
> by not only acpi_numa_processor_affinity_init / acpi_numa_x2apic_affinity_init
> but also acpi_numa_memory_affinity_init for the case.
>
> Signed-off-by: Yasuaki Ishimatsu<isimatu.yasuaki@jp.fujitsu.com>
> ---
> arch/x86/mm/srat.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> Index: linux-3.4/arch/x86/mm/srat.c
> ===================================================================
> --- linux-3.4.orig/arch/x86/mm/srat.c 2012-05-21 07:29:13.000000000 +0900
> +++ linux-3.4/arch/x86/mm/srat.c 2012-05-29 05:28:27.353916902 +0900
> @@ -176,6 +176,8 @@ acpi_numa_memory_affinity_init(struct ac
> return;
> }
>
> + node_set(node, numa_nodes_parsed);
> +
But...
I think this patch itself is correct. If a system have cpuless memory node,
acpi_numa_processor_affinity_init / acpi_numa_x2apic_affinity_init can't
find any cpu description. but we need memory node allocation.
> printk(KERN_INFO "SRAT: Node %u PXM %u %Lx-%Lx\n", node, pxm,
> start, end);
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Patch] x86 : set numa_nodes_parsed at acpi_numa_memory_affinity_init
2012-05-31 11:25 ` KOSAKI Motohiro
@ 2012-05-31 12:39 ` Jiang Liu
2012-06-01 11:08 ` Yasuaki Ishimatsu
1 sibling, 0 replies; 6+ messages in thread
From: Jiang Liu @ 2012-05-31 12:39 UTC (permalink / raw)
To: KOSAKI Motohiro; +Cc: Yasuaki Ishimatsu, hpa, mingo, tglx, x86, linux-kernel
On 05/31/2012 07:25 PM, KOSAKI Motohiro wrote:
> Hi Ishimatsu-san,
>
>
> (5/29/12 3:45 AM), Yasuaki Ishimatsu wrote:
>> When hot-adding a CPU into my system, the system showed following message
>> since node_to_cpumask_map[2] was not allocated memory.
>>
>> Booting Node 2 Processor 32 APIC 0xc0
>> node_to_cpumask_map[2] NULL
>> Pid: 0, comm: swapper/32 Tainted: G A 3.3.5-acd #21
>> Call Trace:
>> [<ffffffff81048845>] debug_cpumask_set_cpu+0x155/0x160
>> [<ffffffff8105e28a>] ? add_timer_on+0xaa/0x120
>> [<ffffffff8150665f>] numa_add_cpu+0x1e/0x22
>> [<ffffffff815020bb>] identify_cpu+0x1df/0x1e4
>> [<ffffffff815020d6>] identify_econdary_cpu+0x16/0x1d
>> [<ffffffff81504614>] smp_store_cpu_info+0x3c/0x3e
>> [<ffffffff81505263>] smp_callin+0x139/0x1be
>> [<ffffffff815052fb>] start_secondary+0x13/0xeb
>>
>> In my investigation, the root cause is that the bit of node 2 was not set at
>> numa_nodes_parsed since hot-added cpu was not written in ACPI SRAT Table.
>> But hot-added memory which is same PXM as the cpu is written in here.
>
> I don't understand this explanation. If cpu is not written in srat table,
> it is firmware bug. isn't it? srat table should describe all possible cpus.
> Why doesn't your system describe cpu info in acpi table?
>
>>
>> ACPI Spec Rev 5.0 says about ACPI SRAT talbe as follows:
>> This optional table provides information that allows OSPM to associate
>> processors and memory ranges, including ranges of memory provided by
>> hot-added memory devices, with system localities / proximity domains
>> and clock domains.
>>
>> So I think the ACPI SRAT Table is not wrong. Thus numa_nodes_parsed should be set
>> by not only acpi_numa_processor_affinity_init / acpi_numa_x2apic_affinity_init
>> but also acpi_numa_memory_affinity_init for the case.
>>
>> Signed-off-by: Yasuaki Ishimatsu<isimatu.yasuaki@jp.fujitsu.com>
>> ---
>> arch/x86/mm/srat.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> Index: linux-3.4/arch/x86/mm/srat.c
>> ===================================================================
>> --- linux-3.4.orig/arch/x86/mm/srat.c 2012-05-21 07:29:13.000000000 +0900
>> +++ linux-3.4/arch/x86/mm/srat.c 2012-05-29 05:28:27.353916902 +0900
>> @@ -176,6 +176,8 @@ acpi_numa_memory_affinity_init(struct ac
>> return;
>> }
>>
>> + node_set(node, numa_nodes_parsed);
>> +
>
> But...
> I think this patch itself is correct. If a system have cpuless memory node,
> acpi_numa_processor_affinity_init / acpi_numa_x2apic_affinity_init can't
> find any cpu description. but we need memory node allocation.
SRAT table only provides information for CPUs present at boot time.
For hot-added CPUs, the _PXM and _SLI methods provide the same information for them
as SRAT table.
>
>
>> printk(KERN_INFO "SRAT: Node %u PXM %u %Lx-%Lx\n", node, pxm,
>> start, end);
>> }
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> 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-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Patch] x86 : set numa_nodes_parsed at acpi_numa_memory_affinity_init
2012-05-29 7:45 [Patch] x86 : set numa_nodes_parsed at acpi_numa_memory_affinity_init Yasuaki Ishimatsu
2012-05-31 11:25 ` KOSAKI Motohiro
@ 2012-05-31 20:37 ` David Rientjes
1 sibling, 0 replies; 6+ messages in thread
From: David Rientjes @ 2012-05-31 20:37 UTC (permalink / raw)
To: Yasuaki Ishimatsu; +Cc: hpa, mingo, tglx, x86, linux-kernel
On Tue, 29 May 2012, Yasuaki Ishimatsu wrote:
> When hot-adding a CPU into my system, the system showed following message
> since node_to_cpumask_map[2] was not allocated memory.
>
> Booting Node 2 Processor 32 APIC 0xc0
> node_to_cpumask_map[2] NULL
> Pid: 0, comm: swapper/32 Tainted: G A 3.3.5-acd #21
> Call Trace:
> [<ffffffff81048845>] debug_cpumask_set_cpu+0x155/0x160
> [<ffffffff8105e28a>] ? add_timer_on+0xaa/0x120
> [<ffffffff8150665f>] numa_add_cpu+0x1e/0x22
> [<ffffffff815020bb>] identify_cpu+0x1df/0x1e4
> [<ffffffff815020d6>] identify_econdary_cpu+0x16/0x1d
> [<ffffffff81504614>] smp_store_cpu_info+0x3c/0x3e
> [<ffffffff81505263>] smp_callin+0x139/0x1be
> [<ffffffff815052fb>] start_secondary+0x13/0xeb
>
> In my investigation, the root cause is that the bit of node 2 was not set at
> numa_nodes_parsed since hot-added cpu was not written in ACPI SRAT Table.
> But hot-added memory which is same PXM as the cpu is written in here.
>
> ACPI Spec Rev 5.0 says about ACPI SRAT talbe as follows:
> This optional table provides information that allows OSPM to associate
> processors and memory ranges, including ranges of memory provided by
> hot-added memory devices, with system localities / proximity domains
> and clock domains.
>
> So I think the ACPI SRAT Table is not wrong. Thus numa_nodes_parsed should be set
> by not only acpi_numa_processor_affinity_init / acpi_numa_x2apic_affinity_init
> but also acpi_numa_memory_affinity_init for the case.
>
> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: David Rientjes <rientjes@google.com>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Patch] x86 : set numa_nodes_parsed at acpi_numa_memory_affinity_init
2012-05-31 11:25 ` KOSAKI Motohiro
2012-05-31 12:39 ` Jiang Liu
@ 2012-06-01 11:08 ` Yasuaki Ishimatsu
2012-06-01 17:09 ` KOSAKI Motohiro
1 sibling, 1 reply; 6+ messages in thread
From: Yasuaki Ishimatsu @ 2012-06-01 11:08 UTC (permalink / raw)
To: KOSAKI Motohiro; +Cc: hpa, mingo, tglx, x86, linux-kernel, rientjes
Hi Kosaki-san,
2012/05/31 20:25, KOSAKI Motohiro wrote:
> Hi Ishimatsu-san,
>
>
> (5/29/12 3:45 AM), Yasuaki Ishimatsu wrote:
>> When hot-adding a CPU into my system, the system showed following message
>> since node_to_cpumask_map[2] was not allocated memory.
>>
>> Booting Node 2 Processor 32 APIC 0xc0
>> node_to_cpumask_map[2] NULL
>> Pid: 0, comm: swapper/32 Tainted: G A 3.3.5-acd #21
>> Call Trace:
>> [<ffffffff81048845>] debug_cpumask_set_cpu+0x155/0x160
>> [<ffffffff8105e28a>] ? add_timer_on+0xaa/0x120
>> [<ffffffff8150665f>] numa_add_cpu+0x1e/0x22
>> [<ffffffff815020bb>] identify_cpu+0x1df/0x1e4
>> [<ffffffff815020d6>] identify_econdary_cpu+0x16/0x1d
>> [<ffffffff81504614>] smp_store_cpu_info+0x3c/0x3e
>> [<ffffffff81505263>] smp_callin+0x139/0x1be
>> [<ffffffff815052fb>] start_secondary+0x13/0xeb
>>
>> In my investigation, the root cause is that the bit of node 2 was not set at
>> numa_nodes_parsed since hot-added cpu was not written in ACPI SRAT Table.
>> But hot-added memory which is same PXM as the cpu is written in here.
>
> I don't understand this explanation. If cpu is not written in srat table,
> it is firmware bug. isn't it? srat table should describe all possible cpus.
> Why doesn't your system describe cpu info in acpi table?
As jiang answered, hot-added CPU need not be written in SRAT Table.
So I don't think it is firmware bug.
Thanks,
Yasuaki Ishimatsu
>
>>
>> ACPI Spec Rev 5.0 says about ACPI SRAT talbe as follows:
>> This optional table provides information that allows OSPM to associate
>> processors and memory ranges, including ranges of memory provided by
>> hot-added memory devices, with system localities / proximity domains
>> and clock domains.
>>
>> So I think the ACPI SRAT Table is not wrong. Thus numa_nodes_parsed should be set
>> by not only acpi_numa_processor_affinity_init / acpi_numa_x2apic_affinity_init
>> but also acpi_numa_memory_affinity_init for the case.
>>
>> Signed-off-by: Yasuaki Ishimatsu<isimatu.yasuaki@jp.fujitsu.com>
>> ---
>> arch/x86/mm/srat.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> Index: linux-3.4/arch/x86/mm/srat.c
>> ===================================================================
>> --- linux-3.4.orig/arch/x86/mm/srat.c 2012-05-21 07:29:13.000000000 +0900
>> +++ linux-3.4/arch/x86/mm/srat.c 2012-05-29 05:28:27.353916902 +0900
>> @@ -176,6 +176,8 @@ acpi_numa_memory_affinity_init(struct ac
>> return;
>> }
>>
>> + node_set(node, numa_nodes_parsed);
>> +
>
> But...
> I think this patch itself is correct. If a system have cpuless memory node,
> acpi_numa_processor_affinity_init / acpi_numa_x2apic_affinity_init can't
> find any cpu description. but we need memory node allocation.
>
>
>> printk(KERN_INFO "SRAT: Node %u PXM %u %Lx-%Lx\n", node, pxm,
>> start, end);
>> }
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> 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-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Patch] x86 : set numa_nodes_parsed at acpi_numa_memory_affinity_init
2012-06-01 11:08 ` Yasuaki Ishimatsu
@ 2012-06-01 17:09 ` KOSAKI Motohiro
0 siblings, 0 replies; 6+ messages in thread
From: KOSAKI Motohiro @ 2012-06-01 17:09 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: KOSAKI Motohiro, hpa, mingo, tglx, x86, linux-kernel, rientjes
(6/1/12 7:08 AM), Yasuaki Ishimatsu wrote:
> Hi Kosaki-san,
>
> 2012/05/31 20:25, KOSAKI Motohiro wrote:
>> Hi Ishimatsu-san,
>>
>>
>> (5/29/12 3:45 AM), Yasuaki Ishimatsu wrote:
>>> When hot-adding a CPU into my system, the system showed following message
>>> since node_to_cpumask_map[2] was not allocated memory.
>>>
>>> Booting Node 2 Processor 32 APIC 0xc0
>>> node_to_cpumask_map[2] NULL
>>> Pid: 0, comm: swapper/32 Tainted: G A 3.3.5-acd #21
>>> Call Trace:
>>> [<ffffffff81048845>] debug_cpumask_set_cpu+0x155/0x160
>>> [<ffffffff8105e28a>] ? add_timer_on+0xaa/0x120
>>> [<ffffffff8150665f>] numa_add_cpu+0x1e/0x22
>>> [<ffffffff815020bb>] identify_cpu+0x1df/0x1e4
>>> [<ffffffff815020d6>] identify_econdary_cpu+0x16/0x1d
>>> [<ffffffff81504614>] smp_store_cpu_info+0x3c/0x3e
>>> [<ffffffff81505263>] smp_callin+0x139/0x1be
>>> [<ffffffff815052fb>] start_secondary+0x13/0xeb
>>>
>>> In my investigation, the root cause is that the bit of node 2 was not set at
>>> numa_nodes_parsed since hot-added cpu was not written in ACPI SRAT Table.
>>> But hot-added memory which is same PXM as the cpu is written in here.
>>
>> I don't understand this explanation. If cpu is not written in srat table,
>> it is firmware bug. isn't it? srat table should describe all possible cpus.
>> Why doesn't your system describe cpu info in acpi table?
>
> As jiang answered, hot-added CPU need not be written in SRAT Table.
> So I don't think it is firmware bug.
If so, please write it to the description. Your changelog was unclear. Other than that,
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-06-01 17:09 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-29 7:45 [Patch] x86 : set numa_nodes_parsed at acpi_numa_memory_affinity_init Yasuaki Ishimatsu
2012-05-31 11:25 ` KOSAKI Motohiro
2012-05-31 12:39 ` Jiang Liu
2012-06-01 11:08 ` Yasuaki Ishimatsu
2012-06-01 17:09 ` KOSAKI Motohiro
2012-05-31 20:37 ` David Rientjes
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).