From: David Hildenbrand <david@redhat.com>
To: Mike Rapoport <rppt@linux.ibm.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 12:04:21 +0200 [thread overview]
Message-ID: <98166184-3aaf-479e-bfb3-fc737f4ac98d@redhat.com> (raw)
In-Reply-To: <20200708094549.GA781326@linux.ibm.com>
On 08.07.20 11:45, Mike Rapoport wrote:
> On Wed, Jul 08, 2020 at 11:25:36AM +0200, David Hildenbrand wrote:
>> On 08.07.20 11:15, Mike Rapoport wrote:
>>>>>>>>
>>>>> But on more theoretical/fundmanetal level, I think we lack a generic
>>>>> abstraction similar to e.g. x86 'struct numa_meminfo' that serves as
>>>>> translaton of firmware supplied information into data that can be used
>>>>> by the generic mm without need to reimplement it for each and every
>>>>> arch.
>>>>
>>>> Right. As I expressed, I am not a friend of using memblock for that, and
>>>> the pgdat node span is tricky.
>>>>
>>>> Maybe abstracting that x86 concept is possible in some way (and we could
>>>> restrict the information to boot-time properties, so we don't have to
>>>> mess with memory hot(un)plug - just as done for numa_meminfo AFAIKS).
>>>
>>> I agree with pgdat part and disagree about memblock. It already has
>>> non-init physmap, why won't we add memblock.memory to the mix? ;-)
>>
>> Can we generalize and tweak physmap to contain node info? That's all we
>> need, no? (the special mem= parameter handling should not matter for our
>> use case, where "physmap" and "memory" would differ)
>
> TBH, I have only random vague thoughts at the moment. This might be an
> option. But then we need to enable physmap on !s390, right?
Yes, looks like it.
>
>>> Now, seriously, memblock already has all the necessary information about
>>> the coldplug memory for several architectures. x86 being an exception
>>> because for some reason the reserved memory is not considered memory
>>> there. The infrastructure for quiering and iterating memory regions is
>>> already there. We just need to leave out the irrelevant parts, like
>>> memblock.reserved and allocation funcions.
>>
>> I *really* don't want to mess with memblocks on memory hot(un)plug on
>> x86 and s390x (+other architectures in the future). I also thought about
>> stopping to create memblocks for hotplugged memory on arm64, by tweaking
>> pfn_valid() to query memblocks only for early sections.
>>
>> If "physmem" is not an option, can we at least introduce something like
>> ARCH_UPDTAE_MEMBLOCK_ON_HOTPLUG to avoid doing that on x86 and s390x for
>> now (and later maybe for others)?
>
> I have to do more memory hotplug howework to answer that ;-)
>
> My general point is that we don't have to reinvent the wheel to have
> coldplug memory representation, it's already there. We just need a way
> to use it properly.
Yes, I tend to agree. Details to be clarified :)
--
Thanks,
David / dhildenb
_______________________________________________
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: David Hildenbrand <david@redhat.com>
To: Mike Rapoport <rppt@linux.ibm.com>
Cc: Mike Rapoport <rppt@kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
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 12:04:21 +0200 [thread overview]
Message-ID: <98166184-3aaf-479e-bfb3-fc737f4ac98d@redhat.com> (raw)
In-Reply-To: <20200708094549.GA781326@linux.ibm.com>
On 08.07.20 11:45, Mike Rapoport wrote:
> On Wed, Jul 08, 2020 at 11:25:36AM +0200, David Hildenbrand wrote:
>> On 08.07.20 11:15, Mike Rapoport wrote:
>>>>>>>>
>>>>> But on more theoretical/fundmanetal level, I think we lack a generic
>>>>> abstraction similar to e.g. x86 'struct numa_meminfo' that serves as
>>>>> translaton of firmware supplied information into data that can be used
>>>>> by the generic mm without need to reimplement it for each and every
>>>>> arch.
>>>>
>>>> Right. As I expressed, I am not a friend of using memblock for that, and
>>>> the pgdat node span is tricky.
>>>>
>>>> Maybe abstracting that x86 concept is possible in some way (and we could
>>>> restrict the information to boot-time properties, so we don't have to
>>>> mess with memory hot(un)plug - just as done for numa_meminfo AFAIKS).
>>>
>>> I agree with pgdat part and disagree about memblock. It already has
>>> non-init physmap, why won't we add memblock.memory to the mix? ;-)
>>
>> Can we generalize and tweak physmap to contain node info? That's all we
>> need, no? (the special mem= parameter handling should not matter for our
>> use case, where "physmap" and "memory" would differ)
>
> TBH, I have only random vague thoughts at the moment. This might be an
> option. But then we need to enable physmap on !s390, right?
Yes, looks like it.
>
>>> Now, seriously, memblock already has all the necessary information about
>>> the coldplug memory for several architectures. x86 being an exception
>>> because for some reason the reserved memory is not considered memory
>>> there. The infrastructure for quiering and iterating memory regions is
>>> already there. We just need to leave out the irrelevant parts, like
>>> memblock.reserved and allocation funcions.
>>
>> I *really* don't want to mess with memblocks on memory hot(un)plug on
>> x86 and s390x (+other architectures in the future). I also thought about
>> stopping to create memblocks for hotplugged memory on arm64, by tweaking
>> pfn_valid() to query memblocks only for early sections.
>>
>> If "physmem" is not an option, can we at least introduce something like
>> ARCH_UPDTAE_MEMBLOCK_ON_HOTPLUG to avoid doing that on x86 and s390x for
>> now (and later maybe for others)?
>
> I have to do more memory hotplug howework to answer that ;-)
>
> My general point is that we don't have to reinvent the wheel to have
> coldplug memory representation, it's already there. We just need a way
> to use it properly.
Yes, I tend to agree. Details to be clarified :)
--
Thanks,
David / dhildenb
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Mike Rapoport <rppt@linux.ibm.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 12:04:21 +0200 [thread overview]
Message-ID: <98166184-3aaf-479e-bfb3-fc737f4ac98d@redhat.com> (raw)
In-Reply-To: <20200708094549.GA781326@linux.ibm.com>
On 08.07.20 11:45, Mike Rapoport wrote:
> On Wed, Jul 08, 2020 at 11:25:36AM +0200, David Hildenbrand wrote:
>> On 08.07.20 11:15, Mike Rapoport wrote:
>>>>>>>>
>>>>> But on more theoretical/fundmanetal level, I think we lack a generic
>>>>> abstraction similar to e.g. x86 'struct numa_meminfo' that serves as
>>>>> translaton of firmware supplied information into data that can be used
>>>>> by the generic mm without need to reimplement it for each and every
>>>>> arch.
>>>>
>>>> Right. As I expressed, I am not a friend of using memblock for that, and
>>>> the pgdat node span is tricky.
>>>>
>>>> Maybe abstracting that x86 concept is possible in some way (and we could
>>>> restrict the information to boot-time properties, so we don't have to
>>>> mess with memory hot(un)plug - just as done for numa_meminfo AFAIKS).
>>>
>>> I agree with pgdat part and disagree about memblock. It already has
>>> non-init physmap, why won't we add memblock.memory to the mix? ;-)
>>
>> Can we generalize and tweak physmap to contain node info? That's all we
>> need, no? (the special mem= parameter handling should not matter for our
>> use case, where "physmap" and "memory" would differ)
>
> TBH, I have only random vague thoughts at the moment. This might be an
> option. But then we need to enable physmap on !s390, right?
Yes, looks like it.
>
>>> Now, seriously, memblock already has all the necessary information about
>>> the coldplug memory for several architectures. x86 being an exception
>>> because for some reason the reserved memory is not considered memory
>>> there. The infrastructure for quiering and iterating memory regions is
>>> already there. We just need to leave out the irrelevant parts, like
>>> memblock.reserved and allocation funcions.
>>
>> I *really* don't want to mess with memblocks on memory hot(un)plug on
>> x86 and s390x (+other architectures in the future). I also thought about
>> stopping to create memblocks for hotplugged memory on arm64, by tweaking
>> pfn_valid() to query memblocks only for early sections.
>>
>> If "physmem" is not an option, can we at least introduce something like
>> ARCH_UPDTAE_MEMBLOCK_ON_HOTPLUG to avoid doing that on x86 and s390x for
>> now (and later maybe for others)?
>
> I have to do more memory hotplug howework to answer that ;-)
>
> My general point is that we don't have to reinvent the wheel to have
> coldplug memory representation, it's already there. We just need a way
> to use it properly.
Yes, I tend to agree. Details to be clarified :)
--
Thanks,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-07-08 10:04 UTC|newest]
Thread overview: 162+ 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-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 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 [this message]
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 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
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 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 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: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 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: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: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 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: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: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 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: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 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: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: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 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-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 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-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=98166184-3aaf-479e-bfb3-fc737f4ac98d@redhat.com \
--to=david@redhat.com \
--cc=Kaly.Xin@arm.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=catalin.marinas@arm.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=rppt@linux.ibm.com \
--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.