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 DE694C433E1 for ; Wed, 8 Jul 2020 06:53:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BDB3820760 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" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729990AbgGHGxw (ORCPT ); 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-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" 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.