* [PATCH v2 0/3] m68k: switch to MEMBLOCK + NO_BOOTMEM
@ 2018-07-04 6:28 Mike Rapoport
2018-07-04 6:28 ` [PATCH v2 1/3] m68k/bitops: convert __ffs to match generic declaration Mike Rapoport
` (4 more replies)
0 siblings, 5 replies; 17+ messages in thread
From: Mike Rapoport @ 2018-07-04 6:28 UTC (permalink / raw)
To: Geert Uytterhoeven, Greg Ungerer, Sam Creasey
Cc: Michal Hocko, linux-m68k, linux-mm, linux-kernel, Mike Rapoport
Hi,
These patches switch m68k boot time memory allocators from bootmem to
memblock + no_bootmem.
The first two patches update __ffs() and __va() definitions to be inline
with other arches and asm-generic. This is required to avoid compilation
warnings in mm/memblock.c and mm/nobootmem.c.
The third patch performs the actual switch of the boot time mm. Its
changelog has detailed description of the changes.
I've tested the !MMU version with qemu-system-m68k -M mcf5208evb
and the MMU version with q800 using qemu from [1].
I've also build tested allyesconfig and *_defconfig.
[1] https://github.com/vivier/qemu-m68k.git
v2:
* fix reservation of the kernel text/data/bss for ColdFire MMU
Mike Rapoport (3):
m68k/bitops: convert __ffs to match generic declaration
m68k/page_no.h: force __va argument to be unsigned long
m68k: switch to MEMBLOCK + NO_BOOTMEM
arch/m68k/Kconfig | 3 +++
arch/m68k/include/asm/bitops.h | 8 ++++++--
arch/m68k/include/asm/page_no.h | 2 +-
arch/m68k/kernel/setup_mm.c | 14 ++++----------
arch/m68k/kernel/setup_no.c | 20 ++++----------------
arch/m68k/mm/init.c | 1 -
arch/m68k/mm/mcfmmu.c | 13 +++++++------
arch/m68k/mm/motorola.c | 35 +++++++++++------------------------
arch/m68k/sun3/config.c | 4 ----
9 files changed, 36 insertions(+), 64 deletions(-)
--
2.7.4
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH v2 1/3] m68k/bitops: convert __ffs to match generic declaration 2018-07-04 6:28 [PATCH v2 0/3] m68k: switch to MEMBLOCK + NO_BOOTMEM Mike Rapoport @ 2018-07-04 6:28 ` Mike Rapoport 2018-07-04 6:28 ` [PATCH v2 2/3] m68k/page_no.h: force __va argument to be unsigned long Mike Rapoport ` (3 subsequent siblings) 4 siblings, 0 replies; 17+ messages in thread From: Mike Rapoport @ 2018-07-04 6:28 UTC (permalink / raw) To: Geert Uytterhoeven, Greg Ungerer, Sam Creasey Cc: Michal Hocko, linux-m68k, linux-mm, linux-kernel, Mike Rapoport The generic bitops declare __ffs as static inline unsigned long __ffs(unsigned long word); Convert the m68k version to match the generic declaration. Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com> --- arch/m68k/include/asm/bitops.h | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/m68k/include/asm/bitops.h b/arch/m68k/include/asm/bitops.h index 93b47b1..54009ea 100644 --- a/arch/m68k/include/asm/bitops.h +++ b/arch/m68k/include/asm/bitops.h @@ -454,7 +454,7 @@ static inline unsigned long ffz(unsigned long word) */ #if (defined(__mcfisaaplus__) || defined(__mcfisac__)) && \ !defined(CONFIG_M68000) && !defined(CONFIG_MCPU32) -static inline int __ffs(int x) +static inline unsigned long __ffs(unsigned long x) { __asm__ __volatile__ ("bitrev %0; ff1 %0" : "=d" (x) @@ -493,7 +493,11 @@ static inline int ffs(int x) : "dm" (x & -x)); return 32 - cnt; } -#define __ffs(x) (ffs(x) - 1) + +static inline unsigned long __ffs(unsigned long x) +{ + return ffs(x) - 1; +} /* * fls: find last bit set. -- 2.7.4 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v2 2/3] m68k/page_no.h: force __va argument to be unsigned long 2018-07-04 6:28 [PATCH v2 0/3] m68k: switch to MEMBLOCK + NO_BOOTMEM Mike Rapoport 2018-07-04 6:28 ` [PATCH v2 1/3] m68k/bitops: convert __ffs to match generic declaration Mike Rapoport @ 2018-07-04 6:28 ` Mike Rapoport 2018-07-04 6:28 ` [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM Mike Rapoport ` (2 subsequent siblings) 4 siblings, 0 replies; 17+ messages in thread From: Mike Rapoport @ 2018-07-04 6:28 UTC (permalink / raw) To: Geert Uytterhoeven, Greg Ungerer, Sam Creasey Cc: Michal Hocko, linux-m68k, linux-mm, linux-kernel, Mike Rapoport Add explicit casting to unsigned long to the __va() parameter Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com> --- arch/m68k/include/asm/page_no.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/m68k/include/asm/page_no.h b/arch/m68k/include/asm/page_no.h index e644c4d..6bbe520 100644 --- a/arch/m68k/include/asm/page_no.h +++ b/arch/m68k/include/asm/page_no.h @@ -18,7 +18,7 @@ extern unsigned long memory_end; #define __HAVE_ARCH_ALLOC_ZEROED_USER_HIGHPAGE #define __pa(vaddr) ((unsigned long)(vaddr)) -#define __va(paddr) ((void *)(paddr)) +#define __va(paddr) ((void *)((unsigned long)(paddr))) #define virt_to_pfn(kaddr) (__pa(kaddr) >> PAGE_SHIFT) #define pfn_to_virt(pfn) __va((pfn) << PAGE_SHIFT) -- 2.7.4 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM 2018-07-04 6:28 [PATCH v2 0/3] m68k: switch to MEMBLOCK + NO_BOOTMEM Mike Rapoport 2018-07-04 6:28 ` [PATCH v2 1/3] m68k/bitops: convert __ffs to match generic declaration Mike Rapoport 2018-07-04 6:28 ` [PATCH v2 2/3] m68k/page_no.h: force __va argument to be unsigned long Mike Rapoport @ 2018-07-04 6:28 ` Mike Rapoport 2018-07-04 7:44 ` Geert Uytterhoeven 2018-07-05 12:13 ` [PATCH v2 0/3] " Greg Ungerer 2018-07-18 11:39 ` Geert Uytterhoeven 4 siblings, 1 reply; 17+ messages in thread From: Mike Rapoport @ 2018-07-04 6:28 UTC (permalink / raw) To: Geert Uytterhoeven, Greg Ungerer, Sam Creasey Cc: Michal Hocko, linux-m68k, linux-mm, linux-kernel, Mike Rapoport In m68k the physical memory is described by [memory_start, memory_end] for !MMU variant and by m68k_memory array of memory ranges for the MMU version. This information is directly use to register the physical memory with memblock. The reserve_bootmem() calls are replaced with memblock_reserve() and the bootmap bitmap allocation is simply dropped. Since the MMU variant creates early mappings only for the small part of the memory we force bottom-up allocations in memblock. Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com> --- arch/m68k/Kconfig | 3 +++ arch/m68k/kernel/setup_mm.c | 14 ++++---------- arch/m68k/kernel/setup_no.c | 20 ++++---------------- arch/m68k/mm/init.c | 1 - arch/m68k/mm/mcfmmu.c | 13 +++++++------ arch/m68k/mm/motorola.c | 35 +++++++++++------------------------ arch/m68k/sun3/config.c | 4 ---- 7 files changed, 29 insertions(+), 61 deletions(-) diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig index 785612b..bd7f38a 100644 --- a/arch/m68k/Kconfig +++ b/arch/m68k/Kconfig @@ -24,6 +24,9 @@ config M68K select MODULES_USE_ELF_RELA select OLD_SIGSUSPEND3 select OLD_SIGACTION + select HAVE_MEMBLOCK + select ARCH_DISCARD_MEMBLOCK + select NO_BOOTMEM config CPU_BIG_ENDIAN def_bool y diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c index f35e3eb..6512955 100644 --- a/arch/m68k/kernel/setup_mm.c +++ b/arch/m68k/kernel/setup_mm.c @@ -21,6 +21,7 @@ #include <linux/string.h> #include <linux/init.h> #include <linux/bootmem.h> +#include <linux/memblock.h> #include <linux/proc_fs.h> #include <linux/seq_file.h> #include <linux/module.h> @@ -165,6 +166,8 @@ static void __init m68k_parse_bootinfo(const struct bi_record *record) be32_to_cpu(m->addr); m68k_memory[m68k_num_memory].size = be32_to_cpu(m->size); + memblock_add(m68k_memory[m68k_num_memory].addr, + m68k_memory[m68k_num_memory].size); m68k_num_memory++; } else pr_warn("%s: too many memory chunks\n", @@ -224,10 +227,6 @@ static void __init m68k_parse_bootinfo(const struct bi_record *record) void __init setup_arch(char **cmdline_p) { -#ifndef CONFIG_SUN3 - int i; -#endif - /* The bootinfo is located right after the kernel */ if (!CPU_IS_COLDFIRE) m68k_parse_bootinfo((const struct bi_record *)_end); @@ -356,14 +355,9 @@ void __init setup_arch(char **cmdline_p) #endif #ifndef CONFIG_SUN3 - for (i = 1; i < m68k_num_memory; i++) - free_bootmem_node(NODE_DATA(i), m68k_memory[i].addr, - m68k_memory[i].size); #ifdef CONFIG_BLK_DEV_INITRD if (m68k_ramdisk.size) { - reserve_bootmem_node(__virt_to_node(phys_to_virt(m68k_ramdisk.addr)), - m68k_ramdisk.addr, m68k_ramdisk.size, - BOOTMEM_DEFAULT); + memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size); initrd_start = (unsigned long)phys_to_virt(m68k_ramdisk.addr); initrd_end = initrd_start + m68k_ramdisk.size; pr_info("initrd: %08lx - %08lx\n", initrd_start, initrd_end); diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c index a98af10..3e8d87a 100644 --- a/arch/m68k/kernel/setup_no.c +++ b/arch/m68k/kernel/setup_no.c @@ -28,6 +28,7 @@ #include <linux/errno.h> #include <linux/string.h> #include <linux/bootmem.h> +#include <linux/memblock.h> #include <linux/seq_file.h> #include <linux/init.h> #include <linux/initrd.h> @@ -86,8 +87,6 @@ void (*mach_power_off)(void); void __init setup_arch(char **cmdline_p) { - int bootmap_size; - memory_start = PAGE_ALIGN(_ramstart); memory_end = _ramend; @@ -142,6 +141,8 @@ void __init setup_arch(char **cmdline_p) pr_debug("MEMORY -> ROMFS=0x%p-0x%06lx MEM=0x%06lx-0x%06lx\n ", __bss_stop, memory_start, memory_start, memory_end); + memblock_add(memory_start, memory_end - memory_start); + /* Keep a copy of command line */ *cmdline_p = &command_line[0]; memcpy(boot_command_line, command_line, COMMAND_LINE_SIZE); @@ -158,23 +159,10 @@ void __init setup_arch(char **cmdline_p) min_low_pfn = PFN_DOWN(memory_start); max_pfn = max_low_pfn = PFN_DOWN(memory_end); - bootmap_size = init_bootmem_node( - NODE_DATA(0), - min_low_pfn, /* map goes here */ - PFN_DOWN(PAGE_OFFSET), - max_pfn); - /* - * Free the usable memory, we have to make sure we do not free - * the bootmem bitmap so we then reserve it after freeing it :-) - */ - free_bootmem(memory_start, memory_end - memory_start); - reserve_bootmem(memory_start, bootmap_size, BOOTMEM_DEFAULT); - #if defined(CONFIG_UBOOT) && defined(CONFIG_BLK_DEV_INITRD) if ((initrd_start > 0) && (initrd_start < initrd_end) && (initrd_end < memory_end)) - reserve_bootmem(initrd_start, initrd_end - initrd_start, - BOOTMEM_DEFAULT); + memblock_reserve(initrd_start, initrd_end - initrd_start); #endif /* if defined(CONFIG_BLK_DEV_INITRD) */ /* diff --git a/arch/m68k/mm/init.c b/arch/m68k/mm/init.c index 8827b7f..38e2b27 100644 --- a/arch/m68k/mm/init.c +++ b/arch/m68k/mm/init.c @@ -71,7 +71,6 @@ void __init m68k_setup_node(int node) pg_data_table[i] = pg_data_map + node; } #endif - pg_data_map[node].bdata = bootmem_node_data + node; node_set_online(node); } diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c index 2925d79..70dde04 100644 --- a/arch/m68k/mm/mcfmmu.c +++ b/arch/m68k/mm/mcfmmu.c @@ -14,6 +14,7 @@ #include <linux/init.h> #include <linux/string.h> #include <linux/bootmem.h> +#include <linux/memblock.h> #include <asm/setup.h> #include <asm/page.h> @@ -153,31 +154,31 @@ int cf_tlb_miss(struct pt_regs *regs, int write, int dtlb, int extension_word) void __init cf_bootmem_alloc(void) { - unsigned long start_pfn; unsigned long memstart; /* _rambase and _ramend will be naturally page aligned */ m68k_memory[0].addr = _rambase; m68k_memory[0].size = _ramend - _rambase; + memblock_add(m68k_memory[0].addr, m68k_memory[0].size); + /* compute total pages in system */ num_pages = PFN_DOWN(_ramend - _rambase); /* page numbers */ memstart = PAGE_ALIGN(_ramstart); min_low_pfn = PFN_DOWN(_rambase); - start_pfn = PFN_DOWN(memstart); max_pfn = max_low_pfn = PFN_DOWN(_ramend); high_memory = (void *)_ramend; + /* Reserve kernel text/data/bss */ + memblock_reserve(memstart, memstart - _rambase); + m68k_virt_to_node_shift = fls(_ramend - 1) - 6; module_fixup(NULL, __start_fixup, __stop_fixup); - /* setup bootmem data */ + /* setup node data */ m68k_setup_node(0); - memstart += init_bootmem_node(NODE_DATA(0), start_pfn, - min_low_pfn, max_low_pfn); - free_bootmem_node(NODE_DATA(0), memstart, _ramend - memstart); } /* diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c index e490ecc..4e17ecb 100644 --- a/arch/m68k/mm/motorola.c +++ b/arch/m68k/mm/motorola.c @@ -19,6 +19,7 @@ #include <linux/types.h> #include <linux/init.h> #include <linux/bootmem.h> +#include <linux/memblock.h> #include <linux/gfp.h> #include <asm/setup.h> @@ -208,7 +209,7 @@ void __init paging_init(void) { unsigned long zones_size[MAX_NR_ZONES] = { 0, }; unsigned long min_addr, max_addr; - unsigned long addr, size, end; + unsigned long addr; int i; #ifdef DEBUG @@ -253,34 +254,20 @@ void __init paging_init(void) min_low_pfn = availmem >> PAGE_SHIFT; max_pfn = max_low_pfn = max_addr >> PAGE_SHIFT; - for (i = 0; i < m68k_num_memory; i++) { - addr = m68k_memory[i].addr; - end = addr + m68k_memory[i].size; - m68k_setup_node(i); - availmem = PAGE_ALIGN(availmem); - availmem += init_bootmem_node(NODE_DATA(i), - availmem >> PAGE_SHIFT, - addr >> PAGE_SHIFT, - end >> PAGE_SHIFT); - } + /* Reserve kernel text/data/bss and the memory allocated in head.S */ + memblock_reserve(m68k_memory[0].addr, availmem - m68k_memory[0].addr); /* * Map the physical memory available into the kernel virtual - * address space. First initialize the bootmem allocator with - * the memory we already mapped, so map_node() has something - * to allocate. + * address space. Make sure memblock will not try to allocate + * pages beyond the memory we already mapped in head.S */ - addr = m68k_memory[0].addr; - size = m68k_memory[0].size; - free_bootmem_node(NODE_DATA(0), availmem, - min(m68k_init_mapped_size, size) - (availmem - addr)); - map_node(0); - if (size > m68k_init_mapped_size) - free_bootmem_node(NODE_DATA(0), addr + m68k_init_mapped_size, - size - m68k_init_mapped_size); - - for (i = 1; i < m68k_num_memory; i++) + memblock_set_bottom_up(true); + + for (i = 0; i < m68k_num_memory; i++) { + m68k_setup_node(i); map_node(i); + } flush_tlb_all(); diff --git a/arch/m68k/sun3/config.c b/arch/m68k/sun3/config.c index 1d28d38..79a2bb8 100644 --- a/arch/m68k/sun3/config.c +++ b/arch/m68k/sun3/config.c @@ -123,10 +123,6 @@ static void __init sun3_bootmem_alloc(unsigned long memory_start, availmem = memory_start; m68k_setup_node(0); - availmem += init_bootmem(start_page, num_pages); - availmem = (availmem + (PAGE_SIZE-1)) & PAGE_MASK; - - free_bootmem(__pa(availmem), memory_end - (availmem)); } -- 2.7.4 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM 2018-07-04 6:28 ` [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM Mike Rapoport @ 2018-07-04 7:44 ` Geert Uytterhoeven 2018-07-04 7:54 ` Michal Hocko 0 siblings, 1 reply; 17+ messages in thread From: Geert Uytterhoeven @ 2018-07-04 7:44 UTC (permalink / raw) To: Mike Rapoport Cc: Greg Ungerer, Sam Creasey, Michal Hocko, linux-m68k, Linux MM, Linux Kernel Mailing List Hi Mike, On Wed, Jul 4, 2018 at 8:28 AM Mike Rapoport <rppt@linux.vnet.ibm.com> wrote: > In m68k the physical memory is described by [memory_start, memory_end] for > !MMU variant and by m68k_memory array of memory ranges for the MMU version. > This information is directly use to register the physical memory with > memblock. > > The reserve_bootmem() calls are replaced with memblock_reserve() and the > bootmap bitmap allocation is simply dropped. > > Since the MMU variant creates early mappings only for the small part of the > memory we force bottom-up allocations in memblock. > > Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com> Thanks a lot for doing this! My virtual Atari (using ARAnyM) now has +12KiB of memory available: -Memory: 267976K/276480K available (3037K kernel code, 304K rwdata, 792K rodata, 148K init, 168K bss, 8504K reserved, 0K cma-reserved) +Memory: 267988K/276480K available (3036K kernel code, 304K rwdata, 792K rodata, 152K init, 168K bss, 8492K reserved, 0K cma-reserved) However, a WARNING is triggered. With memblock_debug=1: Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC DSP56K SCC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED memblock_reserve: [0x00000000-0x00439fff] paging_init+0x172/0x462 memblock_reserve: [0x0043a000-0x0043afff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0043b000-0x0043bfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0043c000-0x0043cfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0043d000-0x0043dfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0043e000-0x0043efff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0043f000-0x0043ffff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00440000-0x00440fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00441000-0x00441fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00442000-0x00442fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00443000-0x00443fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00444000-0x00444fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00445000-0x00445fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00446000-0x00446fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00447000-0x00447fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00448000-0x00448fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00449000-0x00449fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0044a000-0x0044afff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0044b000-0x0044bfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0044c000-0x0044cfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0044d000-0x0044dfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0044e000-0x0044efff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0044f000-0x0044ffff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00450000-0x00450fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00451000-0x00451fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00452000-0x00452fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00453000-0x00453fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00454000-0x00454fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00455000-0x00455fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00456000-0x00456fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00457000-0x00457fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00458000-0x00458fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00459000-0x00459fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0045a000-0x0045afff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0045b000-0x0045bfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0045c000-0x0045cfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0045d000-0x0045dfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0045e000-0x0045efff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0045f000-0x0045ffff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00460000-0x00460fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00461000-0x00461fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00462000-0x00462fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00463000-0x00463fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00464000-0x00464fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00465000-0x00465fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00466000-0x00466fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00467000-0x00467fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00468000-0x00468fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00469000-0x00469fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0046a000-0x0046afff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0046b000-0x0046bfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0046c000-0x0046cfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0046d000-0x0046dfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0046e000-0x0046efff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0046f000-0x0046ffff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00470000-0x00470fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00471000-0x00471fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00472000-0x00472fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00473000-0x00473fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00474000-0x00474fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00475000-0x00475fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00476000-0x00476fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00477000-0x00477fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00478000-0x00478fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00479000-0x00479fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0047a000-0x0047afff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0047b000-0x0047bfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0047c000-0x0047cfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0047d000-0x0047dfff] __alloc_memory_core_early+0x86/0xb8 On node 0 totalpages: 3584 memblock_virt_alloc_try_nid_nopanic: 147456 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 __wake_up_parent+0xc/0x24 memblock_reserve: [0x0047e000-0x004a1fff] memblock_virt_alloc_internal+0xe4/0x156 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 3584 pages, LIFO batch:0 memblock_virt_alloc_try_nid_nopanic: 4 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 0x4 memblock_reserve: [0x004a2000-0x004a2003] memblock_virt_alloc_internal+0xe4/0x156 On node 1 totalpages: 65536 memblock_virt_alloc_try_nid_nopanic: 2359296 bytes align=0x0 nid=1 from=0x0 max_addr=0x0 netdev_lower_get_next+0x2/0x22 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at mm/memblock.c:230 memblock_find_in_range_node+0x11c/0x1be memblock: bottom-up allocation failed, memory hotunplug may be affected Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 4.18.0-rc3-atari-01343-gf2fb5f2e09a97a3c-dirty #7 Stack from 003c3e20: 003c3e20 0039cf44 00023800 00433000 ffffffff 00001000 00240000 000238aa 00378734 000000e6 004285ac 00000009 00000000 003c3e58 003787c0 003c3e74 003c3ea4 004285ac 00378734 000000e6 003787c0 00000000 00000000 00000001 00000000 00000010 00000000 00428490 003e3856 ffffffff ffffffff 003c3ed0 00044620 003c3ee0 00417a10 00240000 00000010 00000000 00000000 00000001 00000000 00000001 00240000 00000000 00000000 00000000 00001000 003e3856 Call Trace: [<00023800>] __warn+0xa8/0xc2 [<00001000>] kernel_pg_dir+0x0/0x1000 [<00240000>] netdev_lower_get_next+0x2/0x22 [<000238aa>] warn_slowpath_fmt+0x2e/0x36 [<004285ac>] memblock_find_in_range_node+0x11c/0x1be [<004285ac>] memblock_find_in_range_node+0x11c/0x1be [<00428490>] memblock_find_in_range_node+0x0/0x1be [<00044620>] vprintk_func+0x66/0x6e [<00417a10>] memblock_virt_alloc_internal+0xd0/0x156 [<00240000>] netdev_lower_get_next+0x2/0x22 [<00240000>] netdev_lower_get_next+0x2/0x22 [<00001000>] kernel_pg_dir+0x0/0x1000 [<00417b8c>] memblock_virt_alloc_try_nid_nopanic+0x58/0x7a [<00240000>] netdev_lower_get_next+0x2/0x22 [<00001000>] kernel_pg_dir+0x0/0x1000 [<00001000>] kernel_pg_dir+0x0/0x1000 [<00010000>] EXPTBL+0x234/0x400 [<00010000>] EXPTBL+0x234/0x400 [<002f3644>] alloc_node_mem_map+0x4a/0x66 [<00240000>] netdev_lower_get_next+0x2/0x22 [<004155ca>] free_area_init_node+0xe2/0x29e [<00010000>] EXPTBL+0x234/0x400 [<00411392>] paging_init+0x430/0x462 [<00001000>] kernel_pg_dir+0x0/0x1000 [<000427cc>] printk+0x0/0x1a [<00010000>] EXPTBL+0x234/0x400 [<0041084c>] setup_arch+0x1b8/0x22c [<0040e020>] start_kernel+0x4a/0x40a [<0040d344>] _sinittext+0x344/0x9e8 random: get_random_bytes called from 0x3e75d2 with crng_init=0 ---[ end trace 0000000000000000 ]--- memblock_reserve: [0x004a2010-0x006e200f] memblock_virt_alloc_internal+0x116/0x156 DMA zone: 576 pages used for memmap DMA zone: 0 pages reserved DMA zone: 65536 pages, LIFO batch:15 memblock_virt_alloc_try_nid_nopanic: 32 bytes align=0x0 nid=1 from=0x0 max_addr=0x0 0x20 memblock_reserve: [0x006e2010-0x006e202f] memblock_virt_alloc_internal+0x116/0x156 NatFeats found (ARAnyM, 1.0) memblock_reserve: [0x006e3000-0x007e2fff] __alloc_memory_core_early+0x86/0xb8 memblock_virt_alloc_try_nid: 118 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 0x76 memblock_reserve: [0x006e2030-0x006e20a5] memblock_virt_alloc_internal+0xe4/0x156 memblock_virt_alloc_try_nid: 118 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 0x76 memblock_reserve: [0x006e20b0-0x006e2125] memblock_virt_alloc_internal+0xe4/0x156 memblock_virt_alloc_try_nid: 118 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 0x76 memblock_reserve: [0x006e2130-0x006e21a5] memblock_virt_alloc_internal+0xe4/0x156 memblock_virt_alloc_try_nid_nopanic: 4096 bytes align=0x1000 nid=-1 from=0x0 max_addr=0x0 kernel_pg_dir+0x0/0x1000 memblock_reserve: [0x007e3000-0x007e3fff] memblock_virt_alloc_internal+0xe4/0x156 memblock_virt_alloc_try_nid_nopanic: 32768 bytes align=0x1000 nid=-1 from=0x0 max_addr=0x0 atari_keyboard_interrupt+0x94/0x2b2 memblock_reserve: [0x007e4000-0x007ebfff] memblock_virt_alloc_internal+0xe4/0x156 memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 0x4 memblock_reserve: [0x006e21b0-0x006e21b3] memblock_virt_alloc_internal+0xe4/0x156 memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 0x4 memblock_reserve: [0x006e21c0-0x006e21c3] memblock_virt_alloc_internal+0xe4/0x156 memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 0x4 memblock_reserve: [0x006e21d0-0x006e21d3] memblock_virt_alloc_internal+0xe4/0x156 memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 0x4 memblock_reserve: [0x006e21e0-0x006e21e3] memblock_virt_alloc_internal+0xe4/0x156 pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 pcpu-alloc: [0] 0 memblock_virt_alloc_try_nid: 120 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 0x78 memblock_reserve: [0x006e21f0-0x006e2267] memblock_virt_alloc_internal+0xe4/0x156 memblock_virt_alloc_try_nid: 67 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 0x43 memblock_reserve: [0x006e2270-0x006e22b2] memblock_virt_alloc_internal+0xe4/0x156 memblock_virt_alloc_try_nid: 1024 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 0x400 memblock_reserve: [0x006e22c0-0x006e26bf] memblock_virt_alloc_internal+0xe4/0x156 memblock_virt_alloc_try_nid: 1028 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 0x404 memblock_reserve: [0x006e26c0-0x006e2ac3] memblock_virt_alloc_internal+0xe4/0x156 memblock_virt_alloc_try_nid: 160 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 0xa0 memblock_reserve: [0x006e2ad0-0x006e2b6f] memblock_virt_alloc_internal+0xe4/0x156 __memblock_free_early: [0x000000007e3000-0x000000007e3fff] 0x7e3000 Built 2 zonelists, mobility grouping on. Total pages: 68512 Kernel command line: root=/dev/sda1 video=atafb:tthigh debug=par console=tty0 initcall_blacklist=atari_scsi_driver_init BOOT_IMAGE=vmlinux blacklisting initcall atari_scsi_driver_init memblock_reserve: [0x006e2b70-0x006e2b7b] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x006e2b80-0x006e2b96] __alloc_memory_core_early+0x86/0xb8 memblock_virt_alloc_try_nid_nopanic: 262144 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 sys_membarrier+0x12/0xc6 memblock_reserve: [0x007ec000-0x0082bfff] memblock_virt_alloc_internal+0xe4/0x156 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) memblock_virt_alloc_try_nid_nopanic: 131072 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 _I_CALL_TOP+0x660/0x1900 memblock_reserve: [0x0082c000-0x0084bfff] memblock_virt_alloc_internal+0xe4/0x156 Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Sorting __ex_table... Memory: 267988K/276480K available (3036K kernel code, 304K rwdata, 792K rodata, 152K init, 168K bss, 8492K reserved, 0K cma-reserved) Do you have a clue? Thanks again! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM 2018-07-04 7:44 ` Geert Uytterhoeven @ 2018-07-04 7:54 ` Michal Hocko 2018-07-04 8:21 ` Geert Uytterhoeven 2018-07-04 12:22 ` Vlastimil Babka 0 siblings, 2 replies; 17+ messages in thread From: Michal Hocko @ 2018-07-04 7:54 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Mike Rapoport, Greg Ungerer, Sam Creasey, linux-m68k, Linux MM, Linux Kernel Mailing List On Wed 04-07-18 09:44:14, Geert Uytterhoeven wrote: [...] > ------------[ cut here ]------------ > WARNING: CPU: 0 PID: 0 at mm/memblock.c:230 > memblock_find_in_range_node+0x11c/0x1be > memblock: bottom-up allocation failed, memory hotunplug may be affected This only means that hotplugable memory might contain non-movable memory now. But does your system even support memory hotplug. I would be really surprised. So I guess we just want this instead diff --git a/mm/memblock.c b/mm/memblock.c index cc16d70b8333..c0dde95593fd 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -228,7 +228,8 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size, * so we use WARN_ONCE() here to see the stack trace if * fail happens. */ - WARN_ONCE(1, "memblock: bottom-up allocation failed, memory hotunplug may be affected\n"); + WARN_ONCE(IS_ENABLED(CONFIG_MEMORY_HOTREMOVE), + "memblock: bottom-up allocvation failed, memory hotunplug may be affected\n"); } return __memblock_find_range_top_down(start, end, size, align, nid, -- Michal Hocko SUSE Labs ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM 2018-07-04 7:54 ` Michal Hocko @ 2018-07-04 8:21 ` Geert Uytterhoeven 2018-07-04 12:22 ` Vlastimil Babka 1 sibling, 0 replies; 17+ messages in thread From: Geert Uytterhoeven @ 2018-07-04 8:21 UTC (permalink / raw) To: Michal Hocko Cc: Mike Rapoport, Greg Ungerer, Sam Creasey, linux-m68k, Linux MM, Linux Kernel Mailing List Hi Michael, On Wed, Jul 4, 2018 at 9:54 AM Michal Hocko <mhocko@kernel.org> wrote: > On Wed 04-07-18 09:44:14, Geert Uytterhoeven wrote: > [...] > > ------------[ cut here ]------------ > > WARNING: CPU: 0 PID: 0 at mm/memblock.c:230 > > memblock_find_in_range_node+0x11c/0x1be > > memblock: bottom-up allocation failed, memory hotunplug may be affected > > This only means that hotplugable memory might contain non-movable memory > now. But does your system even support memory hotplug. I would be really No it doesn't. > surprised. So I guess we just want this instead > diff --git a/mm/memblock.c b/mm/memblock.c > index cc16d70b8333..c0dde95593fd 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -228,7 +228,8 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size, > * so we use WARN_ONCE() here to see the stack trace if > * fail happens. > */ > - WARN_ONCE(1, "memblock: bottom-up allocation failed, memory hotunplug may be affected\n"); > + WARN_ONCE(IS_ENABLED(CONFIG_MEMORY_HOTREMOVE), > + "memblock: bottom-up allocvation failed, memory hotunplug may be affected\n"); > } > > return __memblock_find_range_top_down(start, end, size, align, nid, Thanks, that does the trick! Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM 2018-07-04 7:54 ` Michal Hocko 2018-07-04 8:21 ` Geert Uytterhoeven @ 2018-07-04 12:22 ` Vlastimil Babka 2018-07-04 12:36 ` Michal Hocko 1 sibling, 1 reply; 17+ messages in thread From: Vlastimil Babka @ 2018-07-04 12:22 UTC (permalink / raw) To: Michal Hocko, Geert Uytterhoeven Cc: Mike Rapoport, Greg Ungerer, Sam Creasey, linux-m68k, Linux MM, Linux Kernel Mailing List On 07/04/2018 09:54 AM, Michal Hocko wrote: > On Wed 04-07-18 09:44:14, Geert Uytterhoeven wrote: > [...] >> ------------[ cut here ]------------ >> WARNING: CPU: 0 PID: 0 at mm/memblock.c:230 >> memblock_find_in_range_node+0x11c/0x1be >> memblock: bottom-up allocation failed, memory hotunplug may be affected > > This only means that hotplugable memory might contain non-movable memory > now. But does your system even support memory hotplug. I would be really > surprised. So I guess we just want this instead > diff --git a/mm/memblock.c b/mm/memblock.c > index cc16d70b8333..c0dde95593fd 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -228,7 +228,8 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size, > * so we use WARN_ONCE() here to see the stack trace if > * fail happens. > */ > - WARN_ONCE(1, "memblock: bottom-up allocation failed, memory hotunplug may be affected\n"); > + WARN_ONCE(IS_ENABLED(CONFIG_MEMORY_HOTREMOVE), > + "memblock: bottom-up allocvation failed, memory hotunplug may be affected\n"); ^ allocation ^ hotremove Makes sense, though. > } > > return __memblock_find_range_top_down(start, end, size, align, nid, > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM 2018-07-04 12:22 ` Vlastimil Babka @ 2018-07-04 12:36 ` Michal Hocko 2018-07-04 12:43 ` Mike Rapoport ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Michal Hocko @ 2018-07-04 12:36 UTC (permalink / raw) To: Vlastimil Babka Cc: Geert Uytterhoeven, Mike Rapoport, Greg Ungerer, Sam Creasey, linux-m68k, Linux MM, Linux Kernel Mailing List [CC Andrew - email thread starts http://lkml.kernel.org/r/1530685696-14672-1-git-send-email-rppt@linux.vnet.ibm.com] OK, so here we go with the full patch. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM 2018-07-04 12:36 ` Michal Hocko @ 2018-07-04 12:43 ` Mike Rapoport 2018-07-04 12:51 ` Michal Hocko 2018-07-04 13:05 ` Geert Uytterhoeven 2018-07-06 6:17 ` Michal Hocko 2 siblings, 1 reply; 17+ messages in thread From: Mike Rapoport @ 2018-07-04 12:43 UTC (permalink / raw) To: Michal Hocko Cc: Vlastimil Babka, Geert Uytterhoeven, Greg Ungerer, Sam Creasey, linux-m68k, Linux MM, Linux Kernel Mailing List On Wed, Jul 04, 2018 at 02:36:27PM +0200, Michal Hocko wrote: > [CC Andrew - email thread starts > http://lkml.kernel.org/r/1530685696-14672-1-git-send-email-rppt@linux.vnet.ibm.com] > > OK, so here we go with the full patch. > > From 0e8432b875d98a7a0d3f757fce2caa8d16a8de15 Mon Sep 17 00:00:00 2001 > From: Michal Hocko <mhocko@suse.com> > Date: Wed, 4 Jul 2018 14:31:46 +0200 > Subject: [PATCH] memblock: do not complain about top-down allocations for > !MEMORY_HOTREMOVE > > Mike Rapoport is converting architectures from bootmem to noboodmem > allocator. While doing so for m68k Geert has noticed that he gets > a scary looking warning > WARNING: CPU: 0 PID: 0 at mm/memblock.c:230 > memblock_find_in_range_node+0x11c/0x1be > memblock: bottom-up allocation failed, memory hotunplug may be affected > Modules linked in: > CPU: 0 PID: 0 Comm: swapper Not tainted > 4.18.0-rc3-atari-01343-gf2fb5f2e09a97a3c-dirty #7 > Stack from 003c3e20: > 003c3e20 0039cf44 00023800 00433000 ffffffff 00001000 00240000 000238aa > 00378734 000000e6 004285ac 00000009 00000000 003c3e58 003787c0 003c3e74 > 003c3ea4 004285ac 00378734 000000e6 003787c0 00000000 00000000 00000001 > 00000000 00000010 00000000 00428490 003e3856 ffffffff ffffffff 003c3ed0 > 00044620 003c3ee0 00417a10 00240000 00000010 00000000 00000000 00000001 > 00000000 00000001 00240000 00000000 00000000 00000000 00001000 003e3856 > Call Trace: [<00023800>] __warn+0xa8/0xc2 > [<00001000>] kernel_pg_dir+0x0/0x1000 > [<00240000>] netdev_lower_get_next+0x2/0x22 > [<000238aa>] warn_slowpath_fmt+0x2e/0x36 > [<004285ac>] memblock_find_in_range_node+0x11c/0x1be > [<004285ac>] memblock_find_in_range_node+0x11c/0x1be > [<00428490>] memblock_find_in_range_node+0x0/0x1be > [<00044620>] vprintk_func+0x66/0x6e > [<00417a10>] memblock_virt_alloc_internal+0xd0/0x156 > [<00240000>] netdev_lower_get_next+0x2/0x22 > [<00240000>] netdev_lower_get_next+0x2/0x22 > [<00001000>] kernel_pg_dir+0x0/0x1000 > [<00417b8c>] memblock_virt_alloc_try_nid_nopanic+0x58/0x7a > [<00240000>] netdev_lower_get_next+0x2/0x22 > [<00001000>] kernel_pg_dir+0x0/0x1000 > [<00001000>] kernel_pg_dir+0x0/0x1000 > [<00010000>] EXPTBL+0x234/0x400 > [<00010000>] EXPTBL+0x234/0x400 > [<002f3644>] alloc_node_mem_map+0x4a/0x66 > [<00240000>] netdev_lower_get_next+0x2/0x22 > [<004155ca>] free_area_init_node+0xe2/0x29e > [<00010000>] EXPTBL+0x234/0x400 > [<00411392>] paging_init+0x430/0x462 > [<00001000>] kernel_pg_dir+0x0/0x1000 > [<000427cc>] printk+0x0/0x1a > [<00010000>] EXPTBL+0x234/0x400 > [<0041084c>] setup_arch+0x1b8/0x22c > [<0040e020>] start_kernel+0x4a/0x40a > [<0040d344>] _sinittext+0x344/0x9e8 > > The warning is basically saying that a top-down allocation can break > memory hotremove because memblock allocation is not movable. But m68k > doesn't even support MEMORY_HOTREMOVE is there is no point to warn > about it. > > Make the warning conditional only to configurations that care. > > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> > Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> > Signed-off-by: Michal Hocko <mhocko@suse.com> > --- > mm/memblock.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/mm/memblock.c b/mm/memblock.c > index 03d48d8835ba..2acec4033389 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -227,7 +227,8 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size, > * so we use WARN_ONCE() here to see the stack trace if > * fail happens. > */ > - WARN_ONCE(1, "memblock: bottom-up allocation failed, memory hotunplug may be affected\n"); > + WARN_ONCE(IS_ENABLED(CONFIG_MEMORY_HOTREMOVE), > + "memblock: bottom-up allocation failed, memory hotremove may be affected\n"); nit: isn't the warning indented too much? > } > > return __memblock_find_range_top_down(start, end, size, align, nid, > -- > 2.18.0 > > -- > Michal Hocko > SUSE Labs > -- Sincerely yours, Mike. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM 2018-07-04 12:43 ` Mike Rapoport @ 2018-07-04 12:51 ` Michal Hocko 2018-07-04 12:57 ` Mike Rapoport 0 siblings, 1 reply; 17+ messages in thread From: Michal Hocko @ 2018-07-04 12:51 UTC (permalink / raw) To: Mike Rapoport Cc: Vlastimil Babka, Geert Uytterhoeven, Greg Ungerer, Sam Creasey, linux-m68k, Linux MM, Linux Kernel Mailing List On Wed 04-07-18 15:43:35, Mike Rapoport wrote: > On Wed, Jul 04, 2018 at 02:36:27PM +0200, Michal Hocko wrote: [...] > > diff --git a/mm/memblock.c b/mm/memblock.c > > index 03d48d8835ba..2acec4033389 100644 > > --- a/mm/memblock.c > > +++ b/mm/memblock.c > > @@ -227,7 +227,8 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size, > > * so we use WARN_ONCE() here to see the stack trace if > > * fail happens. > > */ > > - WARN_ONCE(1, "memblock: bottom-up allocation failed, memory hotunplug may be affected\n"); > > + WARN_ONCE(IS_ENABLED(CONFIG_MEMORY_HOTREMOVE), > > + "memblock: bottom-up allocation failed, memory hotremove may be affected\n"); > > nit: isn't the warning indented too much? this is what vim did for me. The string doesn't fit into 80 even if I indented it to the first bracket. If you feel strongly I can do that though. -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM 2018-07-04 12:51 ` Michal Hocko @ 2018-07-04 12:57 ` Mike Rapoport 0 siblings, 0 replies; 17+ messages in thread From: Mike Rapoport @ 2018-07-04 12:57 UTC (permalink / raw) To: Michal Hocko Cc: Vlastimil Babka, Geert Uytterhoeven, Greg Ungerer, Sam Creasey, linux-m68k, Linux MM, Linux Kernel Mailing List On Wed, Jul 04, 2018 at 02:51:21PM +0200, Michal Hocko wrote: > On Wed 04-07-18 15:43:35, Mike Rapoport wrote: > > On Wed, Jul 04, 2018 at 02:36:27PM +0200, Michal Hocko wrote: > [...] > > > diff --git a/mm/memblock.c b/mm/memblock.c > > > index 03d48d8835ba..2acec4033389 100644 > > > --- a/mm/memblock.c > > > +++ b/mm/memblock.c > > > @@ -227,7 +227,8 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size, > > > * so we use WARN_ONCE() here to see the stack trace if > > > * fail happens. > > > */ > > > - WARN_ONCE(1, "memblock: bottom-up allocation failed, memory hotunplug may be affected\n"); > > > + WARN_ONCE(IS_ENABLED(CONFIG_MEMORY_HOTREMOVE), > > > + "memblock: bottom-up allocation failed, memory hotremove may be affected\n"); > > > > nit: isn't the warning indented too much? > > this is what vim did for me. The string doesn't fit into 80 even if I > indented it to the first bracket. If you feel strongly I can do that > though. Not really. With wrapping if looks better like this :) > -- > Michal Hocko > SUSE Labs > -- Sincerely yours, Mike. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM 2018-07-04 12:36 ` Michal Hocko 2018-07-04 12:43 ` Mike Rapoport @ 2018-07-04 13:05 ` Geert Uytterhoeven 2018-07-04 13:14 ` Michal Hocko 2018-07-06 6:17 ` Michal Hocko 2 siblings, 1 reply; 17+ messages in thread From: Geert Uytterhoeven @ 2018-07-04 13:05 UTC (permalink / raw) To: Michal Hocko Cc: Vlastimil Babka, Mike Rapoport, Greg Ungerer, Sam Creasey, linux-m68k, Linux MM, Linux Kernel Mailing List Hi Michal, On Wed, Jul 4, 2018 at 2:36 PM Michal Hocko <mhocko@kernel.org> wrote: > [CC Andrew - email thread starts > http://lkml.kernel.org/r/1530685696-14672-1-git-send-email-rppt@linux.vnet.ibm.com] > > OK, so here we go with the full patch. > > From 0e8432b875d98a7a0d3f757fce2caa8d16a8de15 Mon Sep 17 00:00:00 2001 > From: Michal Hocko <mhocko@suse.com> > Date: Wed, 4 Jul 2018 14:31:46 +0200 > Subject: [PATCH] memblock: do not complain about top-down allocations for > !MEMORY_HOTREMOVE > > Mike Rapoport is converting architectures from bootmem to noboodmem nobootmem > allocator. While doing so for m68k Geert has noticed that he gets > a scary looking warning > WARNING: CPU: 0 PID: 0 at mm/memblock.c:230 > memblock_find_in_range_node+0x11c/0x1be > memblock: bottom-up allocation failed, memory hotunplug may be affected > The warning is basically saying that a top-down allocation can break > memory hotremove because memblock allocation is not movable. But m68k > doesn't even support MEMORY_HOTREMOVE is there is no point to warn so there is > about it. > > Make the warning conditional only to configurations that care. Still, I'm wondering if the warning is really that unlikely on systems that support hotremove. Or is it due to the low amount of RAM on m68k boxes? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM 2018-07-04 13:05 ` Geert Uytterhoeven @ 2018-07-04 13:14 ` Michal Hocko 0 siblings, 0 replies; 17+ messages in thread From: Michal Hocko @ 2018-07-04 13:14 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Vlastimil Babka, Mike Rapoport, Greg Ungerer, Sam Creasey, linux-m68k, Linux MM, Linux Kernel Mailing List On Wed 04-07-18 15:05:08, Geert Uytterhoeven wrote: > Hi Michal, > > On Wed, Jul 4, 2018 at 2:36 PM Michal Hocko <mhocko@kernel.org> wrote: > > [CC Andrew - email thread starts > > http://lkml.kernel.org/r/1530685696-14672-1-git-send-email-rppt@linux.vnet.ibm.com] > > > > OK, so here we go with the full patch. > > > > From 0e8432b875d98a7a0d3f757fce2caa8d16a8de15 Mon Sep 17 00:00:00 2001 > > From: Michal Hocko <mhocko@suse.com> > > Date: Wed, 4 Jul 2018 14:31:46 +0200 > > Subject: [PATCH] memblock: do not complain about top-down allocations for > > !MEMORY_HOTREMOVE > > > > Mike Rapoport is converting architectures from bootmem to noboodmem > > nobootmem fixed > > > allocator. While doing so for m68k Geert has noticed that he gets > > a scary looking warning > > WARNING: CPU: 0 PID: 0 at mm/memblock.c:230 > > memblock_find_in_range_node+0x11c/0x1be > > memblock: bottom-up allocation failed, memory hotunplug may be affected > > > The warning is basically saying that a top-down allocation can break > > memory hotremove because memblock allocation is not movable. But m68k > > doesn't even support MEMORY_HOTREMOVE is there is no point to warn > > so there is fixed > > about it. > > > > Make the warning conditional only to configurations that care. > > Still, I'm wondering if the warning is really that unlikely on systems > that support > hotremove. Or is it due to the low amount of RAM on m68k boxes? Most likely yes. If you want to have full NUMA nodes hot-removable then the BIOS/FW is supposed to mark them hotplug and then we rely on the available memory on the low physical memory ranges (usually on not 0) to cover all early boot allocations. Hack? Sure thing like the whole memory hotremove, if you ask me. -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM 2018-07-04 12:36 ` Michal Hocko 2018-07-04 12:43 ` Mike Rapoport 2018-07-04 13:05 ` Geert Uytterhoeven @ 2018-07-06 6:17 ` Michal Hocko 2 siblings, 0 replies; 17+ messages in thread From: Michal Hocko @ 2018-07-06 6:17 UTC (permalink / raw) To: Andrew Morton Cc: Vlastimil Babka, Geert Uytterhoeven, Mike Rapoport, Greg Ungerer, Sam Creasey, linux-m68k, Linux MM, Linux Kernel Mailing List On Wed 04-07-18 14:36:27, Michal Hocko wrote: > [CC Andrew - email thread starts > http://lkml.kernel.org/r/1530685696-14672-1-git-send-email-rppt@linux.vnet.ibm.com] And updated version with typos fixed ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 0/3] m68k: switch to MEMBLOCK + NO_BOOTMEM 2018-07-04 6:28 [PATCH v2 0/3] m68k: switch to MEMBLOCK + NO_BOOTMEM Mike Rapoport ` (2 preceding siblings ...) 2018-07-04 6:28 ` [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM Mike Rapoport @ 2018-07-05 12:13 ` Greg Ungerer 2018-07-18 11:39 ` Geert Uytterhoeven 4 siblings, 0 replies; 17+ messages in thread From: Greg Ungerer @ 2018-07-05 12:13 UTC (permalink / raw) To: Mike Rapoport, Geert Uytterhoeven, Sam Creasey Cc: Michal Hocko, linux-m68k, linux-mm, linux-kernel Hi Mike, On 04/07/18 16:28, Mike Rapoport wrote: > These patches switch m68k boot time memory allocators from bootmem to > memblock + no_bootmem. > > The first two patches update __ffs() and __va() definitions to be inline > with other arches and asm-generic. This is required to avoid compilation > warnings in mm/memblock.c and mm/nobootmem.c. > > The third patch performs the actual switch of the boot time mm. Its > changelog has detailed description of the changes. > > I've tested the !MMU version with qemu-system-m68k -M mcf5208evb > and the MMU version with q800 using qemu from [1]. > > I've also build tested allyesconfig and *_defconfig. > > [1] https://github.com/vivier/qemu-m68k.git > > v2: > * fix reservation of the kernel text/data/bss for ColdFire MMU I am happy with all of these, so for me: Acked-by: Greg Ungerer <gerg@linux-m68k.org> Regards Greg > Mike Rapoport (3): > m68k/bitops: convert __ffs to match generic declaration > m68k/page_no.h: force __va argument to be unsigned long > m68k: switch to MEMBLOCK + NO_BOOTMEM > > arch/m68k/Kconfig | 3 +++ > arch/m68k/include/asm/bitops.h | 8 ++++++-- > arch/m68k/include/asm/page_no.h | 2 +- > arch/m68k/kernel/setup_mm.c | 14 ++++---------- > arch/m68k/kernel/setup_no.c | 20 ++++---------------- > arch/m68k/mm/init.c | 1 - > arch/m68k/mm/mcfmmu.c | 13 +++++++------ > arch/m68k/mm/motorola.c | 35 +++++++++++------------------------ > arch/m68k/sun3/config.c | 4 ---- > 9 files changed, 36 insertions(+), 64 deletions(-) > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 0/3] m68k: switch to MEMBLOCK + NO_BOOTMEM 2018-07-04 6:28 [PATCH v2 0/3] m68k: switch to MEMBLOCK + NO_BOOTMEM Mike Rapoport ` (3 preceding siblings ...) 2018-07-05 12:13 ` [PATCH v2 0/3] " Greg Ungerer @ 2018-07-18 11:39 ` Geert Uytterhoeven 4 siblings, 0 replies; 17+ messages in thread From: Geert Uytterhoeven @ 2018-07-18 11:39 UTC (permalink / raw) To: Mike Rapoport Cc: Greg Ungerer, Sam Creasey, Michal Hocko, linux-m68k, Linux MM, Linux Kernel Mailing List Hi Mike, On Wed, Jul 4, 2018 at 8:28 AM Mike Rapoport <rppt@linux.vnet.ibm.com> wrote: > These patches switch m68k boot time memory allocators from bootmem to > memblock + no_bootmem. > > The first two patches update __ffs() and __va() definitions to be inline > with other arches and asm-generic. This is required to avoid compilation > warnings in mm/memblock.c and mm/nobootmem.c. > > The third patch performs the actual switch of the boot time mm. Its > changelog has detailed description of the changes. > > I've tested the !MMU version with qemu-system-m68k -M mcf5208evb > and the MMU version with q800 using qemu from [1]. > > I've also build tested allyesconfig and *_defconfig. > > [1] https://github.com/vivier/qemu-m68k.git > > v2: > * fix reservation of the kernel text/data/bss for ColdFire MMU Boots fine on the real Amiga, too. Let's assume it works on Sun 3 too. Thanks a lot, applied and queued for v4.19. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2018-07-18 11:39 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-07-04 6:28 [PATCH v2 0/3] m68k: switch to MEMBLOCK + NO_BOOTMEM Mike Rapoport 2018-07-04 6:28 ` [PATCH v2 1/3] m68k/bitops: convert __ffs to match generic declaration Mike Rapoport 2018-07-04 6:28 ` [PATCH v2 2/3] m68k/page_no.h: force __va argument to be unsigned long Mike Rapoport 2018-07-04 6:28 ` [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM Mike Rapoport 2018-07-04 7:44 ` Geert Uytterhoeven 2018-07-04 7:54 ` Michal Hocko 2018-07-04 8:21 ` Geert Uytterhoeven 2018-07-04 12:22 ` Vlastimil Babka 2018-07-04 12:36 ` Michal Hocko 2018-07-04 12:43 ` Mike Rapoport 2018-07-04 12:51 ` Michal Hocko 2018-07-04 12:57 ` Mike Rapoport 2018-07-04 13:05 ` Geert Uytterhoeven 2018-07-04 13:14 ` Michal Hocko 2018-07-06 6:17 ` Michal Hocko 2018-07-05 12:13 ` [PATCH v2 0/3] " Greg Ungerer 2018-07-18 11:39 ` Geert Uytterhoeven
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).