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=DKIM_SIGNED,DKIM_VALID, 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 59448C433DF for ; Wed, 8 Jul 2020 06:53:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1C7762075B for ; Wed, 8 Jul 2020 06:53:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="TK82CEOe" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1C7762075B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B33FE8D001D; Wed, 8 Jul 2020 02:53:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ABD1A8D000D; Wed, 8 Jul 2020 02:53:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9364A8D001D; Wed, 8 Jul 2020 02:53:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0061.hostedemail.com [216.40.44.61]) by kanga.kvack.org (Postfix) with ESMTP id 769E18D000D for ; Wed, 8 Jul 2020 02:53:52 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 31A23180AD81D for ; Wed, 8 Jul 2020 06:53:52 +0000 (UTC) X-FDA: 77013993504.16.lead84_301849d26ebb Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id EC92D100E6903 for ; Wed, 8 Jul 2020 06:53:51 +0000 (UTC) X-HE-Tag: lead84_301849d26ebb X-Filterd-Recvd-Size: 5528 Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Wed, 8 Jul 2020 06:53:51 +0000 (UTC) Received: by mail-ed1-f66.google.com with SMTP id dg28so40720906edb.3 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=eJ4wO8sC+lb0ZGKYOe9LcV0OzjOunaWfIVgWmpaxQlI8eR8NkBW+mx5gl8lPdls/w6 9o8GAe8+DeE6N/Iad3TaSadHA2HEv1IfdC22P1qGQN229A9g8xZfsGCKGArGcOJ7Q99g 1oWQJrShTm6oEbu4tQh0HnMz1epFbk6Y86aWksIaKcj1RiuKMnlsKusZ3Iv7i6GvWRCt e7Mruv6TKNmeqjfrcotm6T6ubpNw7/97WBlrFV+Uye4iJpexlHPBCrWt6NtwxToPI8jo wgXZ7QING+apmWP6E3lInoeviarO+g1LZSBsxe299DkS+cU3glluhztw6/JAn00HIKhf 1UUw== X-Gm-Message-State: AOAM532yIJg1AidNhX1jCx3bPMaNkNu2tRSgzxpkvMAYMYh2IaHEFEat q43I0HKnlt3ZjWvHX/vGBt46IftPoHz0LWrw1+OrUA== X-Google-Smtp-Source: ABdhPJzWDULeQmA4RbfXyV27OZ4z7CGs9yHTVKdJ+99n4xIaX6QB9r7/8SCU1NxsX0FBfErjajvE/E1jaCZYv8t+S6M= 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" X-Rspamd-Queue-Id: EC92D100E6903 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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.