| Message ID | 20201217130758.11565-2-osalvador@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Allocate memmap from hotadded memory (per device) | expand |
On 17.12.20 14:07, Oscar Salvador wrote: > In order to use self-hosted memmap array, the platform needs to have > support for CONFIG_SPARSEMEM_VMEMMAP and altmap. > Currently, only arm64, PPC and x86_64 have the support, so enable those > platforms with ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE. "In the first version, only .... will support it". I'd probably split off enabling it per architecture in separate patches and the end of the series. Apart from that looks good. > > ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE will be checked later on to see whether > we can enable this feature or not. > > Signed-off-by: Oscar Salvador <osalvador@suse.de>
On Mon, Jan 11, 2021 at 05:52:19PM +0100, David Hildenbrand wrote: > On 17.12.20 14:07, Oscar Salvador wrote: > > In order to use self-hosted memmap array, the platform needs to have > > support for CONFIG_SPARSEMEM_VMEMMAP and altmap. > > Currently, only arm64, PPC and x86_64 have the support, so enable those > > platforms with ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE. > > "In the first version, only .... will support it". I will try to be more specific. > > I'd probably split off enabling it per architecture in separate patches > and the end of the series. You mean introducing only mm/Kconfig change in this patch, and then arch/*/Kconfig changes in separate patches at the end of the series? I can certainly do that, not sure how much will help with the review, but it might help when bisecting. > Apart from that looks good. Thanks for taking a look David!
On 12.01.21 08:26, Oscar Salvador wrote: > On Mon, Jan 11, 2021 at 05:52:19PM +0100, David Hildenbrand wrote: >> On 17.12.20 14:07, Oscar Salvador wrote: >>> In order to use self-hosted memmap array, the platform needs to have >>> support for CONFIG_SPARSEMEM_VMEMMAP and altmap. >>> Currently, only arm64, PPC and x86_64 have the support, so enable those >>> platforms with ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE. >> >> "In the first version, only .... will support it". > > I will try to be more specific. > >> >> I'd probably split off enabling it per architecture in separate patches >> and the end of the series. > > You mean introducing only mm/Kconfig change in this patch, and then > arch/*/Kconfig changes in separate patches at the end of the series? Yeah, or squashing the leftovers of this patch (3 LOC) into patch #2. > > I can certainly do that, not sure how much will help with the review, > but it might help when bisecting. It's usually nicer to explicitly enable stuff per architecture, stating why it works on that architecture (and in the best case, even was tested!). :)
On Tue, Jan 12, 2021 at 11:12:30AM +0100, David Hildenbrand wrote: > On 12.01.21 08:26, Oscar Salvador wrote: > > You mean introducing only mm/Kconfig change in this patch, and then > > arch/*/Kconfig changes in separate patches at the end of the series? > > Yeah, or squashing the leftovers of this patch (3 LOC) into patch #2. Ok, makes sense. > > I can certainly do that, not sure how much will help with the review, > > but it might help when bisecting. > > It's usually nicer to explicitly enable stuff per architecture, stating > why it works on that architecture (and in the best case, even was > tested!). :) Fine by me. I will prepare another re-spin with that in mind then. It would be great to have some feedback on patch#2 before that (in case you find some time ;-). Thanks!
On 12.01.21 12:17, Oscar Salvador wrote: > On Tue, Jan 12, 2021 at 11:12:30AM +0100, David Hildenbrand wrote: >> On 12.01.21 08:26, Oscar Salvador wrote: >>> You mean introducing only mm/Kconfig change in this patch, and then >>> arch/*/Kconfig changes in separate patches at the end of the series? >> >> Yeah, or squashing the leftovers of this patch (3 LOC) into patch #2. > > Ok, makes sense. > >>> I can certainly do that, not sure how much will help with the review, >>> but it might help when bisecting. >> >> It's usually nicer to explicitly enable stuff per architecture, stating >> why it works on that architecture (and in the best case, even was >> tested!). :) > > Fine by me. > I will prepare another re-spin with that in mind then. > > It would be great to have some feedback on patch#2 before that (in case you find > some time ;-). Yeah, will get to that soon. Mailbox is flooded right now :D
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 33446269f692..2daa29ab9057 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -307,6 +307,10 @@ config ARCH_ENABLE_MEMORY_HOTPLUG config ARCH_ENABLE_MEMORY_HOTREMOVE def_bool y +config ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE + def_bool y + depends on MEMORY_HOTPLUG && SPARSEMEM_VMEMMAP_ENABLE + config SMP def_bool y diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 107bb4319e0e..30322105f145 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -527,6 +527,10 @@ config ARCH_ENABLE_MEMORY_HOTPLUG config ARCH_ENABLE_MEMORY_HOTREMOVE def_bool y +config ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE + def_bool y + depends on MEMORY_HOTPLUG && SPARSEMEM_VMEMMAP_ENABLE + config PPC64_SUPPORTS_MEMORY_FAILURE bool "Add support for memory hwpoison" depends on PPC_BOOK3S_64 diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 42d84d86f1f4..742b29169b47 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2443,6 +2443,10 @@ config ARCH_ENABLE_MEMORY_HOTREMOVE def_bool y depends on MEMORY_HOTPLUG +config ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE + def_bool y + depends on X86_64 && MEMORY_HOTPLUG && SPARSEMEM_VMEMMAP_ENABLE + config USE_PERCPU_NUMA_NODE_ID def_bool y depends on NUMA diff --git a/mm/Kconfig b/mm/Kconfig index 7af1a55b708e..6156114b7974 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -183,6 +183,9 @@ config MEMORY_HOTREMOVE depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE depends on MIGRATION +config ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE + bool + # Heavily threaded applications may benefit from splitting the mm-wide # page_table_lock, so that faults on different parts of the user address # space can be handled with less contention: split it at this NR_CPUS.
In order to use self-hosted memmap array, the platform needs to have support for CONFIG_SPARSEMEM_VMEMMAP and altmap. Currently, only arm64, PPC and x86_64 have the support, so enable those platforms with ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE. ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE will be checked later on to see whether we can enable this feature or not. Signed-off-by: Oscar Salvador <osalvador@suse.de> --- arch/arm64/Kconfig | 4 ++++ arch/powerpc/Kconfig | 4 ++++ arch/x86/Kconfig | 4 ++++ mm/Kconfig | 3 +++ 4 files changed, 15 insertions(+)