Re: [PATCH v2 2/8] mm/memory_hotplug: Rename mhp_restrictions to mhp_modifiers
On 2020-01-08 12:13 p.m., Dan Williams wrote: > On Wed, Jan 8, 2020 at 11:08 AM David Hildenbrand wrote: >> >> >> >>> Am 08.01.2020 um 20:00 schrieb Dan Williams : >>> >>> On Wed, Jan 8, 2020 at 9:17 AM Logan Gunthorpe wrote: > On 2020-01-08 5:28 a.m., David Hildenbrand wrote: > On 07.01.20 21:59, Logan Gunthorpe wrote: >> The mhp_restrictions struct really doesn't specify anything resembling >> a restriction anymore so rename it to be mhp_modifiers. > > I wonder if something like "mhp_params" would be even better. It's > essentially just a way to avoid changing call chains rough-out all archs > whenever we want to add a new parameter. Sure, that does sound a bit nicer to me. I can change it for v3. >>> >>> Oh, I was just about to chime in to support "modifiers" because I >>> would expect all parameters to folded into a "params" struct. The >>> modifiers seem to be limited to the set of items that are only >>> considered in a non-default / expert memory hotplug use cases. >> >> It‘s a set of extended parameters I‘d say. > Sure, we can call them "mhp_params" and just clarify that they are > optional / extended in the kernel-doc. Well pgprot isn't going to be optional... But I'll add something to the kernel_doc. Logan
Re: [PATCH v2 2/8] mm/memory_hotplug: Rename mhp_restrictions to mhp_modifiers
On Wed, Jan 8, 2020 at 11:08 AM David Hildenbrand wrote: > > > > > Am 08.01.2020 um 20:00 schrieb Dan Williams : > > > > On Wed, Jan 8, 2020 at 9:17 AM Logan Gunthorpe wrote: > >> > >> > >> > >>> On 2020-01-08 5:28 a.m., David Hildenbrand wrote: > >>> On 07.01.20 21:59, Logan Gunthorpe wrote: > The mhp_restrictions struct really doesn't specify anything resembling > a restriction anymore so rename it to be mhp_modifiers. > >>> > >>> I wonder if something like "mhp_params" would be even better. It's > >>> essentially just a way to avoid changing call chains rough-out all archs > >>> whenever we want to add a new parameter. > >> > >> Sure, that does sound a bit nicer to me. I can change it for v3. > > > > Oh, I was just about to chime in to support "modifiers" because I > > would expect all parameters to folded into a "params" struct. The > > modifiers seem to be limited to the set of items that are only > > considered in a non-default / expert memory hotplug use cases. > > > > It‘s a set of extended parameters I‘d say. Sure, we can call them "mhp_params" and just clarify that they are optional / extended in the kernel-doc. >
Re: [PATCH v2 2/8] mm/memory_hotplug: Rename mhp_restrictions to mhp_modifiers
> Am 08.01.2020 um 20:00 schrieb Dan Williams : > > On Wed, Jan 8, 2020 at 9:17 AM Logan Gunthorpe wrote: >> >> >> >>> On 2020-01-08 5:28 a.m., David Hildenbrand wrote: >>> On 07.01.20 21:59, Logan Gunthorpe wrote: The mhp_restrictions struct really doesn't specify anything resembling a restriction anymore so rename it to be mhp_modifiers. >>> >>> I wonder if something like "mhp_params" would be even better. It's >>> essentially just a way to avoid changing call chains rough-out all archs >>> whenever we want to add a new parameter. >> >> Sure, that does sound a bit nicer to me. I can change it for v3. > > Oh, I was just about to chime in to support "modifiers" because I > would expect all parameters to folded into a "params" struct. The > modifiers seem to be limited to the set of items that are only > considered in a non-default / expert memory hotplug use cases. > It‘s a set of extended parameters I‘d say.
Re: [PATCH v2 2/8] mm/memory_hotplug: Rename mhp_restrictions to mhp_modifiers
On Wed, Jan 8, 2020 at 9:17 AM Logan Gunthorpe wrote: > > > > On 2020-01-08 5:28 a.m., David Hildenbrand wrote: > > On 07.01.20 21:59, Logan Gunthorpe wrote: > >> The mhp_restrictions struct really doesn't specify anything resembling > >> a restriction anymore so rename it to be mhp_modifiers. > > > > I wonder if something like "mhp_params" would be even better. It's > > essentially just a way to avoid changing call chains rough-out all archs > > whenever we want to add a new parameter. > > Sure, that does sound a bit nicer to me. I can change it for v3. Oh, I was just about to chime in to support "modifiers" because I would expect all parameters to folded into a "params" struct. The modifiers seem to be limited to the set of items that are only considered in a non-default / expert memory hotplug use cases.
Re: [PATCH v2 2/8] mm/memory_hotplug: Rename mhp_restrictions to mhp_modifiers
On 2020-01-08 5:28 a.m., David Hildenbrand wrote: > On 07.01.20 21:59, Logan Gunthorpe wrote: >> The mhp_restrictions struct really doesn't specify anything resembling >> a restriction anymore so rename it to be mhp_modifiers. > > I wonder if something like "mhp_params" would be even better. It's > essentially just a way to avoid changing call chains rough-out all archs > whenever we want to add a new parameter. Sure, that does sound a bit nicer to me. I can change it for v3. Logan
Re: [PATCH v2 2/8] mm/memory_hotplug: Rename mhp_restrictions to mhp_modifiers
On 07.01.20 21:59, Logan Gunthorpe wrote: > The mhp_restrictions struct really doesn't specify anything resembling > a restriction anymore so rename it to be mhp_modifiers. I wonder if something like "mhp_params" would be even better. It's essentially just a way to avoid changing call chains rough-out all archs whenever we want to add a new parameter. -- Thanks, David / dhildenb
[PATCH v2 2/8] mm/memory_hotplug: Rename mhp_restrictions to mhp_modifiers
The mhp_restrictions struct really doesn't specify anything resembling
a restriction anymore so rename it to be mhp_modifiers.
Signed-off-by: Logan Gunthorpe
---
arch/arm64/mm/mmu.c| 4 ++--
arch/ia64/mm/init.c| 4 ++--
arch/powerpc/mm/mem.c | 4 ++--
arch/s390/mm/init.c| 6 +++---
arch/sh/mm/init.c | 4 ++--
arch/x86/mm/init_32.c | 4 ++--
arch/x86/mm/init_64.c | 8
include/linux/memory_hotplug.h | 12 ++--
mm/memory_hotplug.c| 8
mm/memremap.c | 8
10 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 40797cbfba2d..3320406579c3 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1050,7 +1050,7 @@ int p4d_free_pud_page(p4d_t *p4d, unsigned long addr)
#ifdef CONFIG_MEMORY_HOTPLUG
int arch_add_memory(int nid, u64 start, u64 size,
- struct mhp_restrictions *restrictions)
+ struct mhp_modifiers *modifiers)
{
int flags = 0;
@@ -1063,7 +1063,7 @@ int arch_add_memory(int nid, u64 start, u64 size,
memblock_clear_nomap(start, size);
return __add_pages(nid, start >> PAGE_SHIFT, size >> PAGE_SHIFT,
- restrictions);
+ modifiers);
}
void arch_remove_memory(int nid, u64 start, u64 size,
struct vmem_altmap *altmap)
diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index b01d68a2d5d9..daf438e08b96 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -670,13 +670,13 @@ mem_init (void)
#ifdef CONFIG_MEMORY_HOTPLUG
int arch_add_memory(int nid, u64 start, u64 size,
- struct mhp_restrictions *restrictions)
+ struct mhp_modifiers *modifiers)
{
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
int ret;
- ret = __add_pages(nid, start_pfn, nr_pages, restrictions);
+ ret = __add_pages(nid, start_pfn, nr_pages, modifiers);
if (ret)
printk("%s: Problem encountered in __add_pages() as ret=%d\n",
__func__, ret);
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index f5535eae637f..9dd9c3c1be7f 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -127,7 +127,7 @@ static void flush_dcache_range_chunked(unsigned long start,
unsigned long stop,
}
int __ref arch_add_memory(int nid, u64 start, u64 size,
- struct mhp_restrictions *restrictions)
+ struct mhp_modifiers *modifiers)
{
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
@@ -143,7 +143,7 @@ int __ref arch_add_memory(int nid, u64 start, u64 size,
return -EFAULT;
}
- return __add_pages(nid, start_pfn, nr_pages, restrictions);
+ return __add_pages(nid, start_pfn, nr_pages, modifiers);
}
void __ref arch_remove_memory(int nid, u64 start, u64 size,
diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index ac44bd76db4b..a0c88c1c9ad0 100644
--- a/arch/s390/mm/init.c
+++ b/arch/s390/mm/init.c
@@ -268,20 +268,20 @@ device_initcall(s390_cma_mem_init);
#endif /* CONFIG_CMA */
int arch_add_memory(int nid, u64 start, u64 size,
- struct mhp_restrictions *restrictions)
+ struct mhp_modifiers *modifiers)
{
unsigned long start_pfn = PFN_DOWN(start);
unsigned long size_pages = PFN_DOWN(size);
int rc;
- if (WARN_ON_ONCE(restrictions->altmap))
+ if (WARN_ON_ONCE(modifiers->altmap))
return -EINVAL;
rc = vmem_add_mapping(start, size);
if (rc)
return rc;
- rc = __add_pages(nid, start_pfn, size_pages, restrictions);
+ rc = __add_pages(nid, start_pfn, size_pages, modifiers);
if (rc)
vmem_remove_mapping(start, size);
return rc;
diff --git a/arch/sh/mm/init.c b/arch/sh/mm/init.c
index d1b1ff2be17a..7e64f42fb570 100644
--- a/arch/sh/mm/init.c
+++ b/arch/sh/mm/init.c
@@ -406,14 +406,14 @@ void __init mem_init(void)
#ifdef CONFIG_MEMORY_HOTPLUG
int arch_add_memory(int nid, u64 start, u64 size,
- struct mhp_restrictions *restrictions)
+ struct mhp_modifiers *modifiers)
{
unsigned long start_pfn = PFN_DOWN(start);
unsigned long nr_pages = size >> PAGE_SHIFT;
int ret;
/* We only have ZONE_NORMAL, so this is easy.. */
- ret = __add_pages(nid, start_pfn, nr_pages, restrictions);
+ ret = __add_pages(nid, start_pfn, nr_pages, modifiers);
if (unlikely(ret))
printk("%s: Failed, __add_pages() == %d\n", __func__, ret);
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 0a74407ef92e..e6fce2d547f0 100644
