Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp304189ybt; Tue, 7 Jul 2020 23:55:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz2IGeu81aQpJZt9dwfQ+T94ub+f7iT8ZcOXtOG2eLzJ+KnIw3r6GBymK0FyGMooUbVCdAM X-Received: by 2002:a17:906:1697:: with SMTP id s23mr53062971ejd.166.1594191343928; Tue, 07 Jul 2020 23:55:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594191343; cv=none; d=google.com; s=arc-20160816; b=kXRPYkBWTniO78U6MGspTV8DSby5MdnuzXxMU5TYJQ0jpeCEamJ11etrM+e0pnoUjE AXb+RDZukblBUFqgIHIS7M9LfaxKJzdZixzdXO35JQj8eEfWq0P6/AcBsDpvtRVPrYHu atUShJg1ruIQDPci3ohdySIkSaCJEOvnvV9TlZvpvgxrurgM4UYqvR1IZbb33okhToBj wPhB90B5BkA23/DaZPQl9HinqFc6O8ykEGCEp82/YxqADniAWO29OqM7xPCBXlfxK1s/ cUztr18edxBYdlt+CrH+tqwU5dcB1MxKJm25sjANvM6gEpjwUTxsZcntaWoFfHDOWygS favw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=keyDLeonC8frLPJK5duQJ259ChXYsKspJF9lGM2JwDk=; b=edfifoq+zRgBMThV2jjVkT2o2uqsa1uyBK14wteB2LAvsCCzmZmBqHDd6O85ZkOe9n fDOyA/e2712r8b/YNQvV/6xDKHrFZEII30CHuxWkmEzbAcode/yuz5JQlvK1kKufTEbp 8Zfvds+AMSD6IeGIJWPvWq8VW31NkF8t+NXp46hlH33z6g8R0gsp8xtzPcs6LafF5Yhq CGQx4eIC5e5Nl9FSNUlF1lWVR6UUycHwVe5dqydmO76NJZBz4NZPIiu0UINBsQbm0OYB PI3rcMFr3HxYjkZfO4Wi5yX/hbcyiLWWwXli7b78N9OOGj4iLNw2CuBkAsV0MG+6dbOZ Wqsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=TK82CEOe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b18si16006533ejb.89.2020.07.07.23.55.20; Tue, 07 Jul 2020 23:55:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=TK82CEOe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729947AbgGHGxw (ORCPT + 99 others); Wed, 8 Jul 2020 02:53:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35410 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729535AbgGHGxw (ORCPT ); Wed, 8 Jul 2020 02:53:52 -0400 Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B3E93C061755 for ; Tue, 7 Jul 2020 23:53:51 -0700 (PDT) Received: by mail-ed1-x544.google.com with SMTP id a8so39515017edy.1 for ; Tue, 07 Jul 2020 23:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=keyDLeonC8frLPJK5duQJ259ChXYsKspJF9lGM2JwDk=; b=TK82CEOeB8wUtoFdmxlPl9goWXQTwmwz3fiSr8+4rT8AzSHNNgiyKr9SzOXy/lyYf8 gqaMKeXD87fSS3J+6QJP0+LSHMNW0ZGFc9up4RMVAmkS4jbaTwovaSj/bnXzH5YYTWw8 XDbmrRbTJiWIB6TpHSeyaFpbpeKezLxVoHr4En1ZhFpTOC5hVD4ag6e27mzPFkzqDcUx fEwcJ3G7I38S0Hb6/vmtLJwq8ZclIrr/MY4Had/T7LOflv0eZNJVb/E797gXA1c3dP4I Y/LThtVQmuHWyMFoNWoxzJDPdam4biTa84cBlq8Ei4ajOKFco76rSfRzlkdhbIUINB4G kbMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=keyDLeonC8frLPJK5duQJ259ChXYsKspJF9lGM2JwDk=; b=qc0mB35J7usOWDWzl3gf8Vl8CnudtvKrYLPQRBnpAymw+geyxxqWzJyGJYuxoiVywK gVtK46qJCsjto/IRI9L46A//FCkA3V8aFhdhh6VE7BOn+wcZyUUiqqcdvlG+C97mpCWu QOLf5UGKgrQWLCj2Qx8rvpVls1SHHTWXgJDvJk11N/27mBG3PG7cGlu/w+IeV/kaffFf EuArSYSVloVfQ89wV6V1hpgLf/pBtDDjQKr9WlowtQ2Yt1sOESRU/i6Lkt9CkUXyqdbd /QXAOZ2CQVIquzLCTnhZZ+QvyBdAYQZIncSlvpjjFkjNsErT2l1FzlYCPLK0pIP0GhQq mALA== X-Gm-Message-State: AOAM530Qo56aj2eguWqP00AGyYyScu8+il7OiHxsdbRCxLD3zrlViGNq rXTKR2GxLOj/fpKliibfDZ6NtGoRKGpGPHHTIaG+tQ== X-Received: by 2002:a50:d9cb:: with SMTP id x11mr62677191edj.93.1594191230511; Tue, 07 Jul 2020 23:53:50 -0700 (PDT) MIME-Version: 1.0 References: <20200707055917.143653-1-justin.he@arm.com> <20200707055917.143653-2-justin.he@arm.com> <20200707115454.GN5913@dhcp22.suse.cz> <20200708062217.GE386073@linux.ibm.com> In-Reply-To: <20200708062217.GE386073@linux.ibm.com> From: Dan Williams Date: Tue, 7 Jul 2020 23:53:39 -0700 Message-ID: Subject: Re: [PATCH v2 1/3] arm64/numa: export memory_add_physaddr_to_nid as EXPORT_SYMBOL_GPL To: Mike Rapoport Cc: Justin He , Michal Hocko , David Hildenbrand , Catalin Marinas , Will Deacon , Vishal Verma , Dave Jiang , Andrew Morton , Baoquan He , Chuhong Yuan , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-nvdimm@lists.01.org" , Kaly Xin Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 7, 2020 at 11:22 PM Mike Rapoport wrote: [..] > > > Thanks for your suggestion, > > > Could I wrap the codes and let memory_add_physaddr_to_nid simply invoke > > > phys_to_target_node()? > > > > I think it needs to be the reverse. phys_to_target_node() should call > > memory_add_physaddr_to_nid() by default, but fall back to searching > > reserved memory address ranges in memblock. See phys_to_target_node() > > in arch/x86/mm/numa.c. That one uses numa_meminfo instead of memblock, > > but the principle is the same i.e. that a target node may not be > > represented in memblock.memory, but memblock.reserved. I'm working on > > a patch to provide a function similar to get_pfn_range_for_nid() that > > operates on reserved memory. > > Do we really need yet another memblock iterator? > I think only x86 has memory that is not in memblock.memory but only in > memblock.reserved. Well, that's what led me here. EFI has introduced a memory attribute called "EFI Special Purpose Memory". I mapped it to a new Linux concept called Soft Reserved memory (commit b617c5266eed "efi: Common enable/disable infrastructure for EFI soft reservation"). The driver I want to claim that memory, device-dax, wants to be able to look up numa information for an address range that is marked reserved in memblock. The device-dax facility has the ability to either let userspace map a device, or assign the memory backing that device to the page allocator. In both scenarios the driver needs numa info to either populate the 'numa_node' property of the device in sysfs, or to pass an node-id to add_memory_resource() when it is hot-plugged. I was thwarted by the lack of phys_to_target_node() on arm64, and rather than add another stub like memory_add_physaddr_to_nid() I wanted to see if it could be solved properly / generically with memblock data.