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=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1B331C433E1 for ; Wed, 8 Jul 2020 07:40:25 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E054520720 for ; Wed, 8 Jul 2020 07:40:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="LQEOL4ZY" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E054520720 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=rM8NHJxauO6m8qgnsyAHUaI2YidEOSpbJF8ou/MLaKs=; b=LQEOL4ZYe8dxP8ww/oMGcqAdA LxmFpCF+MBblR+EgdlvMvJaBAnso09rVyI7Q2YKSF9KDB7bpn1yublGOjRxgZyZHtC9cnwPE2NVtR nw+OY8mwLoiv/mA75mX6onIn+QYKsHqHyEdm8FmeGtJ+DvGcXwB/ntaUHDmiDJj+zLUoj3gP7H5+I 64GsoyI+KkBHLty1cLGoX3PAu5VoZC50y6I6EP+XOc7v5zs+TkBZ/EdAhKfIW8oJYdHtSKTgL3e81 Q84MuOY6NgmcTVg2OhIwv0OYMtbN9S8CEM1fpqaJkyd3QCz8Wg/7Wo35HfbbxpBeg899dKGJ+foAh oqQSPgC9A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jt4fH-0000nV-70; Wed, 08 Jul 2020 07:38:47 +0000 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jt4fE-0000lj-0s for linux-arm-kernel@lists.infradead.org; Wed, 08 Jul 2020 07:38:45 +0000 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0687YbOu022214; Wed, 8 Jul 2020 03:38:35 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3258t4sts7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Jul 2020 03:38:35 -0400 Received: from m0098393.ppops.net (m0098393.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 0687Z19g024112; Wed, 8 Jul 2020 03:38:34 -0400 Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0a-001b2d01.pphosted.com with ESMTP id 3258t4strc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Jul 2020 03:38:34 -0400 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 0687ajNX019581; Wed, 8 Jul 2020 07:38:31 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma06ams.nl.ibm.com with ESMTP id 322h1h46rw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Jul 2020 07:38:31 +0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 0687cTbS52560072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 8 Jul 2020 07:38:29 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8C271AE045; Wed, 8 Jul 2020 07:38:29 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EB904AE055; Wed, 8 Jul 2020 07:38:27 +0000 (GMT) Received: from linux.ibm.com (unknown [9.148.202.29]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Wed, 8 Jul 2020 07:38:27 +0000 (GMT) Date: Wed, 8 Jul 2020 10:38:26 +0300 From: Mike Rapoport To: David Hildenbrand Subject: Re: [PATCH v2 1/3] arm64/numa: export memory_add_physaddr_to_nid as EXPORT_SYMBOL_GPL Message-ID: <20200708073826.GF386073@linux.ibm.com> References: <20200707055917.143653-1-justin.he@arm.com> <20200707055917.143653-2-justin.he@arm.com> <20200707115454.GN5913@dhcp22.suse.cz> <20200707121302.GB9411@linux.ibm.com> <474f93e7-c709-1a13-5418-29f1777f614c@redhat.com> <20200707180043.GA386073@linux.ibm.com> <20200708052626.GB386073@linux.ibm.com> <9a009cf6-6c30-91ca-a1a5-9aa090c66631@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9a009cf6-6c30-91ca-a1a5-9aa090c66631@redhat.com> X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-08_04:2020-07-08, 2020-07-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 impostorscore=0 cotscore=-2147483648 mlxscore=0 malwarescore=0 priorityscore=1501 mlxlogscore=999 suspectscore=2 phishscore=0 spamscore=0 lowpriorityscore=0 clxscore=1015 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2007080053 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200708_033844_211844_D0F12058 X-CRM114-Status: GOOD ( 37.12 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kaly Xin , Jia He , Baoquan He , linux-nvdimm , Catalin Marinas , Chuhong Yuan , Linux Kernel Mailing List , Michal Hocko , Linux MM , Vishal Verma , Dave Jiang , Dan Williams , Will Deacon , Andrew Morton , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jul 08, 2020 at 09:21:25AM +0200, David Hildenbrand wrote: > On 08.07.20 07:27, Mike Rapoport wrote: > > On Tue, Jul 07, 2020 at 03:05:48PM -0700, Dan Williams wrote: > >> On Tue, Jul 7, 2020 at 11:01 AM Mike Rapoport wrote: > >>> > >>> On Tue, Jul 07, 2020 at 02:26:08PM +0200, David Hildenbrand wrote: > >>>> On 07.07.20 14:13, Mike Rapoport wrote: > >>>>> On Tue, Jul 07, 2020 at 01:54:54PM +0200, Michal Hocko wrote: > >>>>>> On Tue 07-07-20 13:59:15, Jia He wrote: > >>>>>>> This exports memory_add_physaddr_to_nid() for module driver to use. > >>>>>>> > >>>>>>> memory_add_physaddr_to_nid() is a fallback option to get the nid in case > >>>>>>> NUMA_NO_NID is detected. > >>>>>>> > >>>>>>> Suggested-by: David Hildenbrand > >>>>>>> Signed-off-by: Jia He > >>>>>>> --- > >>>>>>> arch/arm64/mm/numa.c | 5 +++-- > >>>>>>> 1 file changed, 3 insertions(+), 2 deletions(-) > >>>>>>> > >>>>>>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c > >>>>>>> index aafcee3e3f7e..7eeb31740248 100644 > >>>>>>> --- a/arch/arm64/mm/numa.c > >>>>>>> +++ b/arch/arm64/mm/numa.c > >>>>>>> @@ -464,10 +464,11 @@ void __init arm64_numa_init(void) > >>>>>>> > >>>>>>> /* > >>>>>>> * We hope that we will be hotplugging memory on nodes we already know about, > >>>>>>> - * such that acpi_get_node() succeeds and we never fall back to this... > >>>>>>> + * such that acpi_get_node() succeeds. But when SRAT is not present, the node > >>>>>>> + * id may be probed as NUMA_NO_NODE by acpi, Here provide a fallback option. > >>>>>>> */ > >>>>>>> int memory_add_physaddr_to_nid(u64 addr) > >>>>>>> { > >>>>>>> - pr_warn("Unknown node for memory at 0x%llx, assuming node 0\n", addr); > >>>>>>> return 0; > >>>>>>> } > >>>>>>> +EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid); > >>>>>> > >>>>>> Does it make sense to export a noop function? Wouldn't make more sense > >>>>>> to simply make it static inline somewhere in a header? I haven't checked > >>>>>> whether there is an easy way to do that sanely bu this just hit my eyes. > >>>>> > >>>>> We'll need to either add a CONFIG_ option or arch specific callback to > >>>>> make both non-empty (x86, powerpc, ia64) and empty (arm64, sh) > >>>>> implementations coexist ... > >>>> > >>>> Note: I have a similar dummy (return 0) patch for s390x lying around here. > >>> > >>> Then we'll call it a tie - 3:3 ;-) > >> > >> So I'd be happy to jump on the train of people wanting to export the > >> ARM stub for this (and add a new ARM stub for phys_to_target_node()), > >> but Will did have a plausibly better idea that I have been meaning to > >> circle back to: > >> > >> http://lore.kernel.org/r/20200325111039.GA32109@willie-the-truck > >> > >> ...i.e. iterate over node data to do the lookup. This would seem to > >> work generically for multiple archs unless I am missing something? > > IIRC, only memory assigned to/onlined to a ZONE is represented in the > pgdat node span. E.g., not offline memory blocks. > > Esp., when hotplugging + onlining consecutive memory, there won't really > be any intersections in most cases if I am not wrong. It would not be > "intersection" but rather "closest fit". > > With overlapping nodes it's even more unclear. Which one to pick? > > > > > I think it would work on arm64, power and, most propbably on s390 > > With only a single dummy node I guess it should work (searching when > there is only a single node does not make too much sense). > > > (David?), but not on x86. x86 does not have reserved memory in pgdat, > > it's never memblock_add()'ed (see e820__memblock_setup()). > > Can you enlighten me why that is relevant for the memory hotplug path? > (or is it just a general comment to make the function as accurate as > possible for all addresses?) phys_to_target_node() on x86 falls back to numa_reserved_meminfo which holds memory that is never listed in a node. > -- > Thanks, > > David / dhildenb > -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel