From: Mike Rapoport <rppt@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>
Cc: Mike Rapoport <rppt@kernel.org>, Michal Hocko <mhocko@kernel.org>,
Jia He <justin.he@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Baoquan He <bhe@redhat.com>, Chuhong Yuan <hslester96@gmail.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
Kaly Xin <Kaly.Xin@arm.com>
Subject: Re: [PATCH v2 1/3] arm64/numa: export memory_add_physaddr_to_nid as EXPORT_SYMBOL_GPL
Date: Wed, 8 Jul 2020 19:47:36 +0300 [thread overview]
Message-ID: <20200708164736.GD781326@linux.ibm.com> (raw)
In-Reply-To: <f80f2466-6e64-b525-dae1-66cb62ceb7f1@redhat.com>
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 <david@redhat.com> 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.
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>
Cc: Kaly Xin <Kaly.Xin@arm.com>, Jia He <justin.he@arm.com>,
Baoquan He <bhe@redhat.com>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Chuhong Yuan <hslester96@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Michal Hocko <mhocko@kernel.org>, Linux MM <linux-mm@kvack.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Vishal Verma <vishal.l.verma@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Will Deacon <will@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mike Rapoport <rppt@kernel.org>
Subject: Re: [PATCH v2 1/3] arm64/numa: export memory_add_physaddr_to_nid as EXPORT_SYMBOL_GPL
Date: Wed, 8 Jul 2020 19:47:36 +0300 [thread overview]
Message-ID: <20200708164736.GD781326@linux.ibm.com> (raw)
In-Reply-To: <f80f2466-6e64-b525-dae1-66cb62ceb7f1@redhat.com>
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 <david@redhat.com> 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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
Mike Rapoport <rppt@kernel.org>, Michal Hocko <mhocko@kernel.org>,
Jia He <justin.he@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Vishal Verma <vishal.l.verma@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Baoquan He <bhe@redhat.com>, Chuhong Yuan <hslester96@gmail.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
Kaly Xin <Kaly.Xin@arm.com>
Subject: Re: [PATCH v2 1/3] arm64/numa: export memory_add_physaddr_to_nid as EXPORT_SYMBOL_GPL
Date: Wed, 8 Jul 2020 19:47:36 +0300 [thread overview]
Message-ID: <20200708164736.GD781326@linux.ibm.com> (raw)
In-Reply-To: <f80f2466-6e64-b525-dae1-66cb62ceb7f1@redhat.com>
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 <david@redhat.com> 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.
next prev parent reply other threads:[~2020-07-08 16:47 UTC|newest]
Thread overview: 141+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-07 5:59 [PATCH v2 0/3] Fix and enable pmem as RAM device on arm64 Jia He
2020-07-07 5:59 ` Jia He
2020-07-07 5:59 ` Jia He
2020-07-07 5:59 ` [PATCH v2 1/3] arm64/numa: export memory_add_physaddr_to_nid as EXPORT_SYMBOL_GPL Jia He
2020-07-07 5:59 ` Jia He
2020-07-07 5:59 ` Jia He
2020-07-07 11:35 ` David Hildenbrand
2020-07-07 11:35 ` David Hildenbrand
2020-07-07 11:35 ` David Hildenbrand
2020-07-07 11:54 ` Michal Hocko
2020-07-07 11:54 ` Michal Hocko
2020-07-07 11:54 ` Michal Hocko
2020-07-07 12:13 ` Mike Rapoport
2020-07-07 12:13 ` Mike Rapoport
2020-07-07 12:13 ` Mike Rapoport
2020-07-07 12:26 ` David Hildenbrand
2020-07-07 12:26 ` David Hildenbrand
2020-07-07 12:26 ` David Hildenbrand
2020-07-07 18:00 ` Mike Rapoport
2020-07-07 18:00 ` Mike Rapoport
2020-07-07 18:00 ` Mike Rapoport
2020-07-07 22:05 ` Dan Williams
2020-07-07 22:05 ` Dan Williams
2020-07-07 22:05 ` Dan Williams
2020-07-08 5:27 ` Mike Rapoport
2020-07-08 5:27 ` Mike Rapoport
2020-07-08 5:27 ` Mike Rapoport
2020-07-08 7:21 ` David Hildenbrand
2020-07-08 7:21 ` David Hildenbrand
2020-07-08 7:21 ` David Hildenbrand
2020-07-08 7:38 ` Mike Rapoport
2020-07-08 7:38 ` Mike Rapoport
2020-07-08 7:38 ` Mike Rapoport
2020-07-08 7:40 ` David Hildenbrand
2020-07-08 7:40 ` David Hildenbrand
2020-07-08 7:40 ` David Hildenbrand
2020-07-08 7:50 ` Dan Williams
2020-07-08 7:50 ` Dan Williams
2020-07-08 7:50 ` Dan Williams
2020-07-08 8:26 ` David Hildenbrand
2020-07-08 8:26 ` David Hildenbrand
2020-07-08 8:26 ` David Hildenbrand
2020-07-08 8:39 ` Mike Rapoport
2020-07-08 8:39 ` Mike Rapoport
2020-07-08 8:39 ` Mike Rapoport
2020-07-08 8:45 ` David Hildenbrand
2020-07-08 8:45 ` David Hildenbrand
2020-07-08 8:45 ` David Hildenbrand
2020-07-08 9:15 ` Mike Rapoport
2020-07-08 9:15 ` Mike Rapoport
2020-07-08 9:15 ` Mike Rapoport
2020-07-08 9:25 ` David Hildenbrand
2020-07-08 9:25 ` David Hildenbrand
2020-07-08 9:25 ` David Hildenbrand
2020-07-08 9:45 ` Mike Rapoport
2020-07-08 9:45 ` Mike Rapoport
2020-07-08 9:45 ` Mike Rapoport
2020-07-08 10:04 ` David Hildenbrand
2020-07-08 10:04 ` David Hildenbrand
2020-07-08 10:04 ` David Hildenbrand
2020-07-08 15:50 ` Dan Williams
2020-07-08 15:50 ` Dan Williams
2020-07-08 15:50 ` Dan Williams
2020-07-08 16:10 ` David Hildenbrand
2020-07-08 16:10 ` David Hildenbrand
2020-07-08 16:10 ` David Hildenbrand
2020-07-08 16:47 ` Mike Rapoport [this message]
2020-07-08 16:47 ` Mike Rapoport
2020-07-08 16:47 ` Mike Rapoport
2020-07-08 2:20 ` Justin He
2020-07-08 2:20 ` Justin He
2020-07-08 2:20 ` Justin He
2020-07-08 3:56 ` Dan Williams
2020-07-08 3:56 ` Dan Williams
2020-07-08 3:56 ` Dan Williams
2020-07-08 4:08 ` Justin He
2020-07-08 4:08 ` Justin He
2020-07-08 4:08 ` Justin He
2020-07-08 4:27 ` Dan Williams
2020-07-08 4:27 ` Dan Williams
2020-07-08 4:27 ` Dan Williams
2020-07-08 6:22 ` Mike Rapoport
2020-07-08 6:22 ` Mike Rapoport
2020-07-08 6:22 ` Mike Rapoport
2020-07-08 6:53 ` Dan Williams
2020-07-08 6:53 ` Dan Williams
2020-07-08 6:53 ` Dan Williams
2020-07-08 6:59 ` David Hildenbrand
2020-07-08 6:59 ` David Hildenbrand
2020-07-08 6:59 ` David Hildenbrand
2020-07-08 7:04 ` Dan Williams
2020-07-08 7:04 ` Dan Williams
2020-07-08 7:04 ` Dan Williams
2020-07-08 7:16 ` David Hildenbrand
2020-07-08 7:16 ` David Hildenbrand
2020-07-08 7:16 ` David Hildenbrand
2020-07-08 7:43 ` Mike Rapoport
2020-07-08 7:43 ` Mike Rapoport
2020-07-08 7:43 ` Mike Rapoport
2020-07-08 5:32 ` Mike Rapoport
2020-07-08 5:32 ` Mike Rapoport
2020-07-08 5:32 ` Mike Rapoport
2020-07-08 5:48 ` Dan Williams
2020-07-08 5:48 ` Dan Williams
2020-07-08 5:48 ` Dan Williams
2020-07-08 6:19 ` Mike Rapoport
2020-07-08 6:19 ` Mike Rapoport
2020-07-08 6:19 ` Mike Rapoport
2020-07-08 6:44 ` Dan Williams
2020-07-08 6:44 ` Dan Williams
2020-07-08 6:44 ` Dan Williams
2020-07-08 6:56 ` Justin He
2020-07-08 6:56 ` Justin He
2020-07-08 6:56 ` Justin He
2020-07-08 7:00 ` David Hildenbrand
2020-07-08 7:00 ` David Hildenbrand
2020-07-08 7:00 ` David Hildenbrand
2020-07-07 5:59 ` [RFC PATCH v2 2/3] device-dax: use fallback nid when numa_node is invalid Jia He
2020-07-07 5:59 ` Jia He
2020-07-07 5:59 ` Jia He
2020-07-07 6:08 ` Justin He
2020-07-07 6:08 ` Justin He
2020-07-07 6:08 ` Justin He
2020-07-07 11:34 ` David Hildenbrand
2020-07-07 11:34 ` David Hildenbrand
2020-07-07 11:34 ` David Hildenbrand
2020-07-08 1:41 ` Justin He
2020-07-08 1:41 ` Justin He
2020-07-08 1:41 ` Justin He
2020-07-07 13:53 ` kernel test robot
2020-07-08 7:07 ` kernel test robot
2020-07-07 5:59 ` [PATCH v2 3/3] mm/memory_hotplug: fix unpaired mem_hotplug_begin/done Jia He
2020-07-07 5:59 ` Jia He
2020-07-07 5:59 ` Jia He
2020-07-07 10:06 ` Michal Hocko
2020-07-07 10:06 ` Michal Hocko
2020-07-07 10:06 ` Michal Hocko
2020-07-07 11:31 ` David Hildenbrand
2020-07-07 11:31 ` David Hildenbrand
2020-07-07 11:31 ` David Hildenbrand
2020-07-10 14:02 ` Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200708164736.GD781326@linux.ibm.com \
--to=rppt@linux.ibm.com \
--cc=Kaly.Xin@arm.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=david@redhat.com \
--cc=hslester96@gmail.com \
--cc=justin.he@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=mhocko@kernel.org \
--cc=rppt@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.