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,SPF_HELO_NONE,SPF_PASS autolearn=no 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 8551AC433E0 for ; Wed, 8 Jul 2020 16:48:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 69A93206F6 for ; Wed, 8 Jul 2020 16:48:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730861AbgGHQsI (ORCPT ); Wed, 8 Jul 2020 12:48:08 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:36946 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730816AbgGHQr5 (ORCPT ); Wed, 8 Jul 2020 12:47:57 -0400 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 068Gl9PB106211; Wed, 8 Jul 2020 12:47:46 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 325hy4g0mb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Jul 2020 12:47:45 -0400 Received: from m0098409.ppops.net (m0098409.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 068GlPXt107652; Wed, 8 Jul 2020 12:47:45 -0400 Received: from ppma06fra.de.ibm.com (48.49.7a9f.ip4.static.sl-reverse.com [159.122.73.72]) by mx0a-001b2d01.pphosted.com with ESMTP id 325hy4g0k7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Jul 2020 12:47:45 -0400 Received: from pps.filterd (ppma06fra.de.ibm.com [127.0.0.1]) by ppma06fra.de.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 068GNCu2017283; Wed, 8 Jul 2020 16:47:42 GMT Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by ppma06fra.de.ibm.com with ESMTP id 322h1gabfg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Jul 2020 16:47:42 +0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 068GleDI53936356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 8 Jul 2020 16:47:40 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4C553AE045; Wed, 8 Jul 2020 16:47:40 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 94F43AE053; Wed, 8 Jul 2020 16:47:38 +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 16:47:38 +0000 (GMT) Date: Wed, 8 Jul 2020 19:47:36 +0300 From: Mike Rapoport To: David Hildenbrand Cc: Dan Williams , Mike Rapoport , Michal Hocko , Jia He , Catalin Marinas , Will Deacon , Vishal Verma , Dave Jiang , Andrew Morton , Baoquan He , Chuhong Yuan , Linux ARM , Linux Kernel Mailing List , Linux MM , linux-nvdimm , Kaly Xin Subject: Re: [PATCH v2 1/3] arm64/numa: export memory_add_physaddr_to_nid as EXPORT_SYMBOL_GPL Message-ID: <20200708164736.GD781326@linux.ibm.com> References: <999ea296-4695-1219-6a4d-a027718f61e5@redhat.com> <20200708083951.GH386073@linux.ibm.com> <20200708091520.GE128651@kernel.org> <20200708094549.GA781326@linux.ibm.com> <98166184-3aaf-479e-bfb3-fc737f4ac98d@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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_13:2020-07-08,2020-07-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 bulkscore=0 lowpriorityscore=0 clxscore=1015 impostorscore=0 spamscore=0 phishscore=0 cotscore=-2147483648 mlxlogscore=999 suspectscore=1 adultscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2007080107 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 08, 2020 at 06:10:19PM +0200, David Hildenbrand wrote: > On 08.07.20 17:50, Dan Williams wrote: > > On Wed, Jul 8, 2020 at 3:04 AM David Hildenbrand wrote: > >> > > > > I'm not quite understanding the concern, or requirement about > > "updating memblock" in the hotplug path. The routines > > memory_add_physaddr_to_nid() and phys_to_target_node() are helpers to > > interrogate platform-firmware numa info through a common abstraction. > > They place no burden on the memory hotplug code they're just used to > > see if a hot-added range lies within an existing node span when > > platform-firmware otherwise fails to communicate a node. x86 can > > continue to back those helpers with numa_meminfo, arm64 can use a > > generic memblock implementation and other archs can follow the arm64 > > example if they want better numa answers for drivers. > > > > See memblock_add_node()/memblock_remove() in mm/memory_hotplug.c. I > don't want that code be reactivated for x86/s390x. That's all I am saying. And these have actual meaning only on arm64 because powerpc does not rely on memblock for memory hot(un)plug, AFAIU. Anyway, at the moment we can use memblock on hotplug path only on arm64 and I don't think its the path worth exploring. > -- > Thanks, > > David / dhildenb > -- Sincerely yours, Mike.