From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by aws-us-west-2-korg-lkml-1.web.codeaurora.org (Postfix) with ESMTP id 6B3FAC433EF for ; Thu, 14 Jun 2018 06:25:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2B087208D4 for ; Thu, 14 Jun 2018 06:25:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2B087208D4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754710AbeFNGY7 (ORCPT ); Thu, 14 Jun 2018 02:24:59 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:51050 "EHLO huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752795AbeFNGY5 (ORCPT ); Thu, 14 Jun 2018 02:24:57 -0400 Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 577E8DAEFAA8C; Thu, 14 Jun 2018 14:24:53 +0800 (CST) Received: from [127.0.0.1] (10.177.223.23) by DGGEMS402-HUB.china.huawei.com (10.3.19.202) with Microsoft SMTP Server id 14.3.382.0; Thu, 14 Jun 2018 14:24:45 +0800 Subject: Re: [PATCH 1/2] arm64: avoid alloc memory on offline node To: Punit Agrawal , Xie XiuQi CC: Bjorn Helgaas , , , Catalin Marinas , "Rafael J. Wysocki" , Will Deacon , Linux Kernel Mailing List , Jarkko Sakkinen , , , Greg Kroah-Hartman , Bjorn Helgaas , Andrew Morton , zhongjiang , linux-arm , Michal Hocko References: <1527768879-88161-2-git-send-email-xiexiuqi@huawei.com> <20180606154516.GL6631@arm.com> <20180607105514.GA13139@dhcp22.suse.cz> <5ed798a0-6c9c-086e-e5e8-906f593ca33e@huawei.com> <20180607122152.GP32433@dhcp22.suse.cz> <20180611085237.GI13364@dhcp22.suse.cz> <16c4db2f-bc70-d0f2-fb38-341d9117ff66@huawei.com> <20180611134303.GC75679@bhelgaas-glaptop.roam.corp.google.com> <20180611145330.GO13364@dhcp22.suse.cz> <87lgbk59gs.fsf@e105922-lin.cambridge.arm.com> <87bmce60y3.fsf@e105922-lin.cambridge.arm.com> From: Hanjun Guo Message-ID: <28ab6a17-dfb6-13d5-764c-d8255569c6bc@huawei.com> Date: Thu, 14 Jun 2018 14:23:59 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <87bmce60y3.fsf@e105922-lin.cambridge.arm.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.223.23] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Punit, On 2018/6/14 1:39, Punit Agrawal wrote: > Punit Agrawal writes: > > > [...] > >> >> CONFIG_HAVE_MEMORYLESS node is not enabled on arm64 which means we end >> up returning the original node in the fallback path. >> >> Xie, does the below patch help? I can submit a proper patch if this >> fixes the issue for you. >> >> -- >8 -- >> Subject: [PATCH] arm64/numa: Enable memoryless numa nodes >> >> Signed-off-by: Punit Agrawal >> --- >> arch/arm64/Kconfig | 4 ++++ >> arch/arm64/mm/numa.c | 2 ++ >> 2 files changed, 6 insertions(+) >> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index eb2cf4938f6d..5317e9aa93ab 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -756,6 +756,10 @@ config USE_PERCPU_NUMA_NODE_ID >> def_bool y >> depends on NUMA >> >> +config HAVE_MEMORYLESS_NODES >> + def_bool y >> + depends on NUMA >> + >> config HAVE_SETUP_PER_CPU_AREA >> def_bool y >> depends on NUMA >> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c >> index dad128ba98bf..c699dcfe93de 100644 >> --- a/arch/arm64/mm/numa.c >> +++ b/arch/arm64/mm/numa.c >> @@ -73,6 +73,8 @@ EXPORT_SYMBOL(cpumask_of_node); >> static void map_cpu_to_node(unsigned int cpu, int nid) >> { >> set_cpu_numa_node(cpu, nid); >> + set_numa_mem(local_memory_node(nid)); > > Argh, this should be > > set_cpu_numa_mem(cpu, local_memory_node(nid)); > > There is not guarantee that map_cpu_to_node() will be called on the > local cpu. > > Hanjun, Xie - can you try with the update please? Thanks for looking into this, we will try this tomorrow (the hardware is occupied now) and update here. Thanks Hanjun