[RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address
The conversion is done using
sed -i 's@memblock_virt_alloc@memblock_alloc@g' \
$(git grep -l memblock_virt_alloc)
Signed-off-by: Mike Rapoport
---
arch/arm/kernel/setup.c | 4 ++--
arch/arm/mach-omap2/omap_hwmod.c | 2 +-
arch/arm64/mm/kasan_init.c| 2 +-
arch/arm64/mm/numa.c | 2 +-
arch/powerpc/kernel/pci_32.c | 2 +-
arch/powerpc/lib/alloc.c | 2 +-
arch/powerpc/mm/mmu_context_nohash.c | 6 ++---
arch/powerpc/platforms/powermac/nvram.c | 2 +-
arch/powerpc/platforms/powernv/pci-ioda.c | 6 ++---
arch/powerpc/platforms/ps3/setup.c| 2 +-
arch/powerpc/sysdev/msi_bitmap.c | 2 +-
arch/s390/kernel/setup.c | 12 +-
arch/s390/kernel/smp.c| 2 +-
arch/s390/kernel/topology.c | 4 ++--
arch/s390/numa/mode_emu.c | 2 +-
arch/s390/numa/toptree.c | 2 +-
arch/x86/mm/kasan_init_64.c | 4 ++--
arch/xtensa/mm/kasan_init.c | 2 +-
drivers/clk/ti/clk.c | 2 +-
drivers/firmware/memmap.c | 2 +-
drivers/of/fdt.c | 2 +-
drivers/of/unittest.c | 2 +-
include/linux/bootmem.h | 38 +++
init/main.c | 6 ++---
kernel/dma/swiotlb.c | 8 +++
kernel/power/snapshot.c | 2 +-
kernel/printk/printk.c| 4 ++--
lib/cpumask.c | 2 +-
mm/hugetlb.c | 2 +-
mm/kasan/kasan_init.c | 2 +-
mm/memblock.c | 26 ++---
mm/page_alloc.c | 8 +++
mm/page_ext.c | 2 +-
mm/percpu.c | 28 +++
mm/sparse-vmemmap.c | 2 +-
mm/sparse.c | 12 +-
36 files changed, 105 insertions(+), 105 deletions(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 4c249cb..39e6090 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -857,7 +857,7 @@ static void __init request_standard_resources(const struct
machine_desc *mdesc)
*/
boot_alias_start = phys_to_idmap(start);
if (arm_has_idmap_alias() && boot_alias_start !=
IDMAP_INVALID_ADDR) {
- res = memblock_virt_alloc(sizeof(*res), 0);
+ res = memblock_alloc(sizeof(*res), 0);
res->name = "System RAM (boot alias)";
res->start = boot_alias_start;
res->end = phys_to_idmap(end);
@@ -865,7 +865,7 @@ static void __init request_standard_resources(const struct
machine_desc *mdesc)
request_resource(&iomem_resource, res);
}
- res = memblock_virt_alloc(sizeof(*res), 0);
+ res = memblock_alloc(sizeof(*res), 0);
res->name = "System RAM";
res->start = start;
res->end = end;
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index cd65ea4..314284e 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -725,7 +725,7 @@ static int __init _setup_clkctrl_provider(struct
device_node *np)
struct clkctrl_provider *provider;
u64 size;
- provider = memblock_virt_alloc(sizeof(*provider), 0);
+ provider = memblock_alloc(sizeof(*provider), 0);
if (!provider)
return -ENOMEM;
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index 1214587..2391560 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -38,7 +38,7 @@ static pgd_t tmp_pg_dir[PTRS_PER_PGD] __initdata
__aligned(PGD_SIZE);
static phys_addr_t __init kasan_alloc_zeroed_page(int node)
{
- void *p = memblock_virt_alloc_try_nid(PAGE_SIZE, PAGE_SIZE,
+ void *p = memblock_alloc_try_nid(PAGE_SIZE, PAGE_SIZE,
__pa(MAX_DMA_ADDRESS),
MEMBLOCK_ALLOC_ACCESSIBLE, node);
return __pa(p);
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index e5aacd6..8f2e0e8 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -168,7 +168,7 @@ static void * __init pcpu_fc_alloc(unsigned int cpu, size_t
size,
{
int nid = early_cpu_to_node(cpu);
- return memblock_virt_alloc_try_nid(size, align,
+ return memblock_alloc_try_nid(size, align,
__pa(MAX_DMA_ADDRESS), MEMBLOCK_ALLOC_ACCESSIBLE, nid);
}
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index d63b488..2fb4781
Re: [RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address
On Wed, Sep 5, 2018 at 11:00 AM Mike Rapoport wrote: > > The conversion is done using > > sed -i 's@memblock_virt_alloc@memblock_alloc@g' \ > $(git grep -l memblock_virt_alloc) What's the reason to do this? It seems like a lot of churn even if a mechanical change. Rob
Re: [RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address
On Wed, Sep 05, 2018 at 12:04:36PM -0500, Rob Herring wrote: > On Wed, Sep 5, 2018 at 11:00 AM Mike Rapoport wrote: > > > > The conversion is done using > > > > sed -i 's@memblock_virt_alloc@memblock_alloc@g' \ > > $(git grep -l memblock_virt_alloc) > > What's the reason to do this? It seems like a lot of churn even if a > mechanical change. I felt that memblock_virt_alloc_ is too long for a prefix, e.g: memblock_virt_alloc_node_nopanic, memblock_virt_alloc_low_nopanic. And for consistency I've changed the memblock_virt_alloc as well. > Rob > -- Sincerely yours, Mike.
Re: [RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address
On Wed 05-09-18 20:20:18, Mike Rapoport wrote: > On Wed, Sep 05, 2018 at 12:04:36PM -0500, Rob Herring wrote: > > On Wed, Sep 5, 2018 at 11:00 AM Mike Rapoport > > wrote: > > > > > > The conversion is done using > > > > > > sed -i 's@memblock_virt_alloc@memblock_alloc@g' \ > > > $(git grep -l memblock_virt_alloc) > > > > What's the reason to do this? It seems like a lot of churn even if a > > mechanical change. > > I felt that memblock_virt_alloc_ is too long for a prefix, e.g: > memblock_virt_alloc_node_nopanic, memblock_virt_alloc_low_nopanic. > > And for consistency I've changed the memblock_virt_alloc as well. I would keep the current API unless the name is terribly misleading or it can be improved a lot. Neither seems to be the case here. So I would rather stick with the status quo. -- Michal Hocko SUSE Labs
Re: [RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address
On Thu, Sep 06, 2018 at 09:28:00AM +0200, Michal Hocko wrote: > On Wed 05-09-18 20:20:18, Mike Rapoport wrote: > > On Wed, Sep 05, 2018 at 12:04:36PM -0500, Rob Herring wrote: > > > On Wed, Sep 5, 2018 at 11:00 AM Mike Rapoport > > > wrote: > > > > > > > > The conversion is done using > > > > > > > > sed -i 's@memblock_virt_alloc@memblock_alloc@g' \ > > > > $(git grep -l memblock_virt_alloc) > > > > > > What's the reason to do this? It seems like a lot of churn even if a > > > mechanical change. > > > > I felt that memblock_virt_alloc_ is too long for a prefix, e.g: > > memblock_virt_alloc_node_nopanic, memblock_virt_alloc_low_nopanic. > > > > And for consistency I've changed the memblock_virt_alloc as well. > > I would keep the current API unless the name is terribly misleading or > it can be improved a lot. Neither seems to be the case here. So I would > rather stick with the status quo. I'm ok with the memblock_virt_alloc by itself, but having 'virt' in 'memblock_virt_alloc_try_nid_nopanic' and 'memblock_virt_alloc_low_nopanic' reduces code readability in my opinion. Besides, from what I've seen, many users of memblock_phys_alloc can be converted to the virtual variant and then we can just have memblock_alloc everywhere in the end. Currently there are ~70 users of memblock_virt_alloc*, but with the bootmem -> memblock conversion we'll be adding ~140 more. > -- > Michal Hocko > SUSE Labs > -- Sincerely yours, Mike.
Re: [RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address
On Thu 06-09-18 15:43:21, Mike Rapoport wrote: > On Thu, Sep 06, 2018 at 09:28:00AM +0200, Michal Hocko wrote: > > On Wed 05-09-18 20:20:18, Mike Rapoport wrote: > > > On Wed, Sep 05, 2018 at 12:04:36PM -0500, Rob Herring wrote: > > > > On Wed, Sep 5, 2018 at 11:00 AM Mike Rapoport > > > > wrote: > > > > > > > > > > The conversion is done using > > > > > > > > > > sed -i 's@memblock_virt_alloc@memblock_alloc@g' \ > > > > > $(git grep -l memblock_virt_alloc) > > > > > > > > What's the reason to do this? It seems like a lot of churn even if a > > > > mechanical change. > > > > > > I felt that memblock_virt_alloc_ is too long for a prefix, e.g: > > > memblock_virt_alloc_node_nopanic, memblock_virt_alloc_low_nopanic. > > > > > > And for consistency I've changed the memblock_virt_alloc as well. > > > > I would keep the current API unless the name is terribly misleading or > > it can be improved a lot. Neither seems to be the case here. So I would > > rather stick with the status quo. > > I'm ok with the memblock_virt_alloc by itself, but having 'virt' in > 'memblock_virt_alloc_try_nid_nopanic' and 'memblock_virt_alloc_low_nopanic' > reduces code readability in my opinion. Well, is _nopanic really really useful in the name. Do we even need/want implicit panic/nopanic semantic? The code should rather check for the return value and decide depending on the code path. I suspect removing panic/nopanic would make the API slightly lighter. -- Michal Hocko SUSE Labs
Re: [RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address
On Thu, Sep 06, 2018 at 03:01:02PM +0200, Michal Hocko wrote: > On Thu 06-09-18 15:43:21, Mike Rapoport wrote: > > On Thu, Sep 06, 2018 at 09:28:00AM +0200, Michal Hocko wrote: > > > On Wed 05-09-18 20:20:18, Mike Rapoport wrote: > > > > On Wed, Sep 05, 2018 at 12:04:36PM -0500, Rob Herring wrote: > > > > > On Wed, Sep 5, 2018 at 11:00 AM Mike Rapoport > > > > > wrote: > > > > > > > > > > > > The conversion is done using > > > > > > > > > > > > sed -i 's@memblock_virt_alloc@memblock_alloc@g' \ > > > > > > $(git grep -l memblock_virt_alloc) > > > > > > > > > > What's the reason to do this? It seems like a lot of churn even if a > > > > > mechanical change. > > > > > > > > I felt that memblock_virt_alloc_ is too long for a prefix, e.g: > > > > memblock_virt_alloc_node_nopanic, memblock_virt_alloc_low_nopanic. > > > > > > > > And for consistency I've changed the memblock_virt_alloc as well. > > > > > > I would keep the current API unless the name is terribly misleading or > > > it can be improved a lot. Neither seems to be the case here. So I would > > > rather stick with the status quo. > > > > I'm ok with the memblock_virt_alloc by itself, but having 'virt' in > > 'memblock_virt_alloc_try_nid_nopanic' and 'memblock_virt_alloc_low_nopanic' > > reduces code readability in my opinion. > > Well, is _nopanic really really useful in the name. Do we even need/want > implicit panic/nopanic semantic? The code should rather check for the > return value and decide depending on the code path. I suspect removing > panic/nopanic would make the API slightly lighter. I agree that panic/nopanic should be removed. But I prefer to start with equivalent replacement to make it as automated as possible and update memblock API when the dust settles a bit. > -- > Michal Hocko > SUSE Labs > -- Sincerely yours, Mike.
Re: [RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address
On Thu 06-09-18 16:39:58, Mike Rapoport wrote: > On Thu, Sep 06, 2018 at 03:01:02PM +0200, Michal Hocko wrote: > > On Thu 06-09-18 15:43:21, Mike Rapoport wrote: > > > On Thu, Sep 06, 2018 at 09:28:00AM +0200, Michal Hocko wrote: > > > > On Wed 05-09-18 20:20:18, Mike Rapoport wrote: > > > > > On Wed, Sep 05, 2018 at 12:04:36PM -0500, Rob Herring wrote: > > > > > > On Wed, Sep 5, 2018 at 11:00 AM Mike Rapoport > > > > > > wrote: > > > > > > > > > > > > > > The conversion is done using > > > > > > > > > > > > > > sed -i 's@memblock_virt_alloc@memblock_alloc@g' \ > > > > > > > $(git grep -l memblock_virt_alloc) > > > > > > > > > > > > What's the reason to do this? It seems like a lot of churn even if a > > > > > > mechanical change. > > > > > > > > > > I felt that memblock_virt_alloc_ is too long for a prefix, e.g: > > > > > memblock_virt_alloc_node_nopanic, memblock_virt_alloc_low_nopanic. > > > > > > > > > > And for consistency I've changed the memblock_virt_alloc as well. > > > > > > > > I would keep the current API unless the name is terribly misleading or > > > > it can be improved a lot. Neither seems to be the case here. So I would > > > > rather stick with the status quo. > > > > > > I'm ok with the memblock_virt_alloc by itself, but having 'virt' in > > > 'memblock_virt_alloc_try_nid_nopanic' and > > > 'memblock_virt_alloc_low_nopanic' > > > reduces code readability in my opinion. > > > > Well, is _nopanic really really useful in the name. Do we even need/want > > implicit panic/nopanic semantic? The code should rather check for the > > return value and decide depending on the code path. I suspect removing > > panic/nopanic would make the API slightly lighter. > > I agree that panic/nopanic should be removed. But I prefer to start with > equivalent replacement to make it as automated as possible and update > memblock API when the dust settles a bit. Yes, I agree with that approach. But that also doesn't justify the renaming -- Michal Hocko SUSE Labs
Re: [RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address
On Thu, Sep 06, 2018 at 03:46:27PM +0200, Michal Hocko wrote: > On Thu 06-09-18 16:39:58, Mike Rapoport wrote: > > On Thu, Sep 06, 2018 at 03:01:02PM +0200, Michal Hocko wrote: > > > On Thu 06-09-18 15:43:21, Mike Rapoport wrote: > > > > On Thu, Sep 06, 2018 at 09:28:00AM +0200, Michal Hocko wrote: > > > > > On Wed 05-09-18 20:20:18, Mike Rapoport wrote: > > > > > > On Wed, Sep 05, 2018 at 12:04:36PM -0500, Rob Herring wrote: > > > > > > > On Wed, Sep 5, 2018 at 11:00 AM Mike Rapoport > > > > > > > wrote: > > > > > > > > > > > > > > > > The conversion is done using > > > > > > > > > > > > > > > > sed -i 's@memblock_virt_alloc@memblock_alloc@g' \ > > > > > > > > $(git grep -l memblock_virt_alloc) > > > > > > > > > > > > > > What's the reason to do this? It seems like a lot of churn even > > > > > > > if a > > > > > > > mechanical change. > > > > > > > > > > > > I felt that memblock_virt_alloc_ is too long for a prefix, e.g: > > > > > > memblock_virt_alloc_node_nopanic, memblock_virt_alloc_low_nopanic. > > > > > > > > > > > > And for consistency I've changed the memblock_virt_alloc as well. > > > > > > > > > > I would keep the current API unless the name is terribly misleading or > > > > > it can be improved a lot. Neither seems to be the case here. So I > > > > > would > > > > > rather stick with the status quo. > > > > > > > > I'm ok with the memblock_virt_alloc by itself, but having 'virt' in > > > > 'memblock_virt_alloc_try_nid_nopanic' and > > > > 'memblock_virt_alloc_low_nopanic' > > > > reduces code readability in my opinion. > > > > > > Well, is _nopanic really really useful in the name. Do we even need/want > > > implicit panic/nopanic semantic? The code should rather check for the > > > return value and decide depending on the code path. I suspect removing > > > panic/nopanic would make the API slightly lighter. > > > > I agree that panic/nopanic should be removed. But I prefer to start with > > equivalent replacement to make it as automated as possible and update > > memblock API when the dust settles a bit. > > Yes, I agree with that approach. But that also doesn't justify the > renaming Well, the renaming is automated :) Anyway, we can continue arguing about keeping or removing _virt regardless of the bootmem -> memblock change. I'll redo the set with memblock_virt_alloc and we can resume the argument later on :) > -- > Michal Hocko > SUSE Labs > -- Sincerely yours, Mike.
Re: [RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address
On Fri 07-09-18 11:42:12, Mike Rapoport wrote: > On Thu, Sep 06, 2018 at 03:46:27PM +0200, Michal Hocko wrote: > > On Thu 06-09-18 16:39:58, Mike Rapoport wrote: > > > On Thu, Sep 06, 2018 at 03:01:02PM +0200, Michal Hocko wrote: > > > > On Thu 06-09-18 15:43:21, Mike Rapoport wrote: > > > > > On Thu, Sep 06, 2018 at 09:28:00AM +0200, Michal Hocko wrote: > > > > > > On Wed 05-09-18 20:20:18, Mike Rapoport wrote: > > > > > > > On Wed, Sep 05, 2018 at 12:04:36PM -0500, Rob Herring wrote: > > > > > > > > On Wed, Sep 5, 2018 at 11:00 AM Mike Rapoport > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > The conversion is done using > > > > > > > > > > > > > > > > > > sed -i 's@memblock_virt_alloc@memblock_alloc@g' \ > > > > > > > > > $(git grep -l memblock_virt_alloc) > > > > > > > > > > > > > > > > What's the reason to do this? It seems like a lot of churn even > > > > > > > > if a > > > > > > > > mechanical change. > > > > > > > > > > > > > > I felt that memblock_virt_alloc_ is too long for a prefix, e.g: > > > > > > > memblock_virt_alloc_node_nopanic, memblock_virt_alloc_low_nopanic. > > > > > > > > > > > > > > And for consistency I've changed the memblock_virt_alloc as well. > > > > > > > > > > > > I would keep the current API unless the name is terribly misleading > > > > > > or > > > > > > it can be improved a lot. Neither seems to be the case here. So I > > > > > > would > > > > > > rather stick with the status quo. > > > > > > > > > > I'm ok with the memblock_virt_alloc by itself, but having 'virt' in > > > > > 'memblock_virt_alloc_try_nid_nopanic' and > > > > > 'memblock_virt_alloc_low_nopanic' > > > > > reduces code readability in my opinion. > > > > > > > > Well, is _nopanic really really useful in the name. Do we even need/want > > > > implicit panic/nopanic semantic? The code should rather check for the > > > > return value and decide depending on the code path. I suspect removing > > > > panic/nopanic would make the API slightly lighter. > > > > > > I agree that panic/nopanic should be removed. But I prefer to start with > > > equivalent replacement to make it as automated as possible and update > > > memblock API when the dust settles a bit. > > > > Yes, I agree with that approach. But that also doesn't justify the > > renaming > > Well, the renaming is automated :) Yes, it is. It also adds churn to the code so I tend to prefer an existing naming unless it is completely misleading or incomprehensible. Is this something to lose sleep over. Absolutely not! Does it make sense to discuss further? I do not think so. If you strongly believe that the renaming is a good thing then just do it. -- Michal Hocko SUSE Labs
Re: [RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address
On Fri, Sep 07, 2018 at 10:47:56AM +0200, Michal Hocko wrote: > On Fri 07-09-18 11:42:12, Mike Rapoport wrote: > > On Thu, Sep 06, 2018 at 03:46:27PM +0200, Michal Hocko wrote: > > > On Thu 06-09-18 16:39:58, Mike Rapoport wrote: > > > > On Thu, Sep 06, 2018 at 03:01:02PM +0200, Michal Hocko wrote: > > > > > On Thu 06-09-18 15:43:21, Mike Rapoport wrote: > > > > > > On Thu, Sep 06, 2018 at 09:28:00AM +0200, Michal Hocko wrote: > > > > > > > On Wed 05-09-18 20:20:18, Mike Rapoport wrote: > > > > > > > > On Wed, Sep 05, 2018 at 12:04:36PM -0500, Rob Herring wrote: > > > > > > > > > On Wed, Sep 5, 2018 at 11:00 AM Mike Rapoport > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > The conversion is done using > > > > > > > > > > > > > > > > > > > > sed -i 's@memblock_virt_alloc@memblock_alloc@g' \ > > > > > > > > > > $(git grep -l memblock_virt_alloc) > > > > > > > > > > > > > > > > > > What's the reason to do this? It seems like a lot of churn > > > > > > > > > even if a > > > > > > > > > mechanical change. > > > > > > > > > > > > > > > > I felt that memblock_virt_alloc_ is too long for a prefix, e.g: > > > > > > > > memblock_virt_alloc_node_nopanic, > > > > > > > > memblock_virt_alloc_low_nopanic. > > > > > > > > > > > > > > > > And for consistency I've changed the memblock_virt_alloc as > > > > > > > > well. > > > > > > > > > > > > > > I would keep the current API unless the name is terribly > > > > > > > misleading or > > > > > > > it can be improved a lot. Neither seems to be the case here. So I > > > > > > > would > > > > > > > rather stick with the status quo. > > > > > > > > > > > > I'm ok with the memblock_virt_alloc by itself, but having 'virt' in > > > > > > 'memblock_virt_alloc_try_nid_nopanic' and > > > > > > 'memblock_virt_alloc_low_nopanic' > > > > > > reduces code readability in my opinion. > > > > > > > > > > Well, is _nopanic really really useful in the name. Do we even > > > > > need/want > > > > > implicit panic/nopanic semantic? The code should rather check for the > > > > > return value and decide depending on the code path. I suspect removing > > > > > panic/nopanic would make the API slightly lighter. > > > > > > > > I agree that panic/nopanic should be removed. But I prefer to start with > > > > equivalent replacement to make it as automated as possible and update > > > > memblock API when the dust settles a bit. > > > > > > Yes, I agree with that approach. But that also doesn't justify the > > > renaming > > > > Well, the renaming is automated :) > > Yes, it is. It also adds churn to the code so I tend to prefer an > existing naming unless it is completely misleading or incomprehensible. > > Is this something to lose sleep over. Absolutely not! Does it make sense > to discuss further? I do not think so. If you strongly believe that the > renaming is a good thing then just do it. I won't lose my sleep over it, but I do believe that renaming is a good thing. I think that in the end we'll be able to reduce the memblock allocation API to a handful of memblock_alloc_ variants instead of ~20 we have now. > -- > Michal Hocko > SUSE Labs > -- Sincerely yours, Mike.
