[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.