From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754372AbcHSBqz (ORCPT ); Thu, 18 Aug 2016 21:46:55 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:27425 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754464AbcHSBpZ (ORCPT ); Thu, 18 Aug 2016 21:45:25 -0400 Message-ID: <57B663E4.30706@huawei.com> Date: Fri, 19 Aug 2016 09:41:56 +0800 From: zhong jiang User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ganapatrao Kulkarni CC: Catalin Marinas , Mark Rutland , Will Deacon , "linux-kernel@vger.kernel.org" , Rob Herring , Ganapatrao Kulkarni , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable References: <1471525766-12803-1-git-send-email-zhongjiang@huawei.com> <20160818160437.GA21343@e104818-lin.cambridge.arm.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.29.68] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.57B6641F.00BD,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a0286e4532f33890841fa1f16512d46e Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/8/19 1:45, Ganapatrao Kulkarni wrote: > On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas > wrote: >> On Thu, Aug 18, 2016 at 09:09:26PM +0800, zhongjiang wrote: >>> At present, boot cpu will bound to a node from device tree when node_off enable. >>> if the node is not initialization, it will lead to a following problem. >>> >>> next_zones_zonelist+0x18/0x80 >>> __build_all_zonelists+0x1e0/0x288 >>> build_all_zonelists_init+0x10/0x1c >>> build_all_zonelists+0x114/0x128 >>> start_kernel+0x1a0/0x414 >> I think this "problem" is missing a lot of information. Is this supposed >> to be a kernel panic? yes, it will leads to kernel crash. the details is as follows. Unable to handle kernel paging request at virtual address 00001690 pgd = ffff800001226000 [00001690] *pgd=0000000000000000 Internal error: Oops: 96000004 [#1] SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.27-vhulk3.6.5.aarch64 #1 Hardware name: Hisilicon Hi1612 Development Board (DT) task: ffff80000102b730 ti: ffff800001018000 task.ti: ffff800001018000 PC is at next_zones_zonelist+0x18/0x80 LR is at __build_all_zonelists+0x1e0/0x288 next_zones_zonelist+0x18/0x80 __build_all_zonelists+0x1e0/0x288 build_all_zonelists_init+0x10/0x1c build_all_zonelists+0x114/0x128 start_kernel+0x1a0/0x414 >>> The patch fix it by fallback to node 0. therefore, the cpu will bound to the node >>> correctly. >>> >>> Signed-off-by: zhongjiang >>> --- >>> arch/arm64/mm/numa.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c >>> index 4dcd7d6..1f8f5da 100644 >>> --- a/arch/arm64/mm/numa.c >>> +++ b/arch/arm64/mm/numa.c >>> @@ -119,7 +119,7 @@ void numa_store_cpu_info(unsigned int cpu) >>> void __init early_map_cpu_to_node(unsigned int cpu, int nid) >>> { >>> /* fallback to node 0 */ >>> - if (nid < 0 || nid >= MAX_NUMNODES) >>> + if (nid < 0 || nid >= MAX_NUMNODES || numa_off) > i did not understood how this line change fixes the issue that you > have mentioned (i too not understood fully the issue description) > this array used while mapping node id when secondary cores comes up > when numa_off is set the cpu_to_node_map[cpu] is not used and set to > node0 always( refer function numa_store_cpu_info).. > please provide more details to understand the issue you are facing. > /* > * Set the cpu to node and mem mapping > */ > void numa_store_cpu_info(unsigned int cpu) > { > map_cpu_to_node(cpu, numa_off ? 0 : cpu_to_node_map[cpu]); > } > > thanks > Ganapat >>> nid = 0; >>> >>> cpu_to_node_map[cpu] = nid; >> The patch looks fine (slight inconsistence from the map_cpu_to_node() >> callers but I guess we don't want to expose numa_off outside this file). >> I would however like to see an Ack from Ganapat (cc'ed). >> >> -- >> Catalin >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > . >