* [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter
@ 2022-03-01 4:28 Tiezhu Yang
2022-03-01 4:28 ` [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter Tiezhu Yang
` (4 more replies)
0 siblings, 5 replies; 26+ messages in thread
From: Tiezhu Yang @ 2022-03-01 4:28 UTC (permalink / raw)
To: Thomas Bogendoerfer, Mike Rapoport, Andrew Morton
Cc: Xuefeng Li, linux-mips, linux-mm, linux-kernel
In the current code, the kernel command-line parameter mem= and memmap=
can not work well on MIPS, this patchset refactors the related code to
fix them.
For kdump on MIPS, if the users want to limit the memory region for the
capture kernel to avoid corrupting the memory image of the panic kernel,
use the parameter memmap=limit@base is the proper way, I will submit a
patch to use memmap=limit@base for kexec-tools after this patchset is
applied.
v4: Fix some build warnings reported by kernel test robot
v3: Modify patch #3 to maintain compatibility for memmap=limit{$,#,!}base,
commented by Mike Rapoport, thank you
v2: Add some new patches to support memmap=limit@base
Tiezhu Yang (4):
MIPS: Refactor early_parse_mem() to fix mem= parameter
memblock: Introduce memblock_mem_range_remove_map()
MIPS: Refactor early_parse_memmap() to fix memmap= parameter
MIPS: Remove not used variable usermem
arch/mips/kernel/setup.c | 69 ++++++++++++++++++++++--------------------------
include/linux/memblock.h | 1 +
mm/memblock.c | 9 +++++--
3 files changed, 40 insertions(+), 39 deletions(-)
--
2.1.0
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter 2022-03-01 4:28 [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter Tiezhu Yang @ 2022-03-01 4:28 ` Tiezhu Yang 2022-03-04 15:10 ` Thomas Bogendoerfer 2022-03-01 4:28 ` [PATCH v4 2/4] memblock: Introduce memblock_mem_range_remove_map() Tiezhu Yang ` (3 subsequent siblings) 4 siblings, 1 reply; 26+ messages in thread From: Tiezhu Yang @ 2022-03-01 4:28 UTC (permalink / raw) To: Thomas Bogendoerfer, Mike Rapoport, Andrew Morton Cc: Xuefeng Li, linux-mips, linux-mm, linux-kernel According to Documentation/admin-guide/kernel-parameters.txt, the kernel command-line parameter mem= means "Force usage of a specific amount of memory", but when add "mem=3G" to the command-line, kernel boot hangs in sparse_init(). This commit is similar with the implementation of the other archs such as arm64, powerpc and riscv, refactor the function early_parse_mem() and then use memblock_enforce_memory_limit() to limit the memory size. With this patch, when add "mem=3G" to the command-line, the kernel boots successfully, we can see the following messages: [ 0.000000] Memory limited to 3072MB ... [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000200000-0x000000000effffff] [ 0.000000] node 0: [mem 0x0000000090200000-0x00000000ffffffff] [ 0.000000] node 0: [mem 0x0000000120000000-0x00000001613fffff] ... [ 0.000000] Memory: 3005280K/3145728K available (...) After login, the output of free command is consistent with the above log. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> --- arch/mips/kernel/setup.c | 26 +++++++++----------------- 1 file changed, 9 insertions(+), 17 deletions(-) diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c index f979adf..50396ba 100644 --- a/arch/mips/kernel/setup.c +++ b/arch/mips/kernel/setup.c @@ -339,27 +339,15 @@ static void __init bootmem_init(void) #endif /* CONFIG_SGI_IP27 */ static int usermem __initdata; +static phys_addr_t memory_limit; static int __init early_parse_mem(char *p) { - phys_addr_t start, size; - - /* - * If a user specifies memory size, we - * blow away any automatically generated - * size. - */ - if (usermem == 0) { - usermem = 1; - memblock_remove(memblock_start_of_DRAM(), - memblock_end_of_DRAM() - memblock_start_of_DRAM()); - } - start = 0; - size = memparse(p, &p); - if (*p == '@') - start = memparse(p + 1, &p); + if (!p) + return 1; - memblock_add(start, size); + memory_limit = memparse(p, &p) & PAGE_MASK; + pr_notice("Memory limited to %lluMB\n", (u64)memory_limit >> 20); return 0; } @@ -678,6 +666,10 @@ static void __init arch_mem_init(char **cmdline_p) memblock_reserve(__pa_symbol(&__nosave_begin), __pa_symbol(&__nosave_end) - __pa_symbol(&__nosave_begin)); + /* Limit the memory. */ + memblock_enforce_memory_limit(memory_limit); + memblock_allow_resize(); + early_memtest(PFN_PHYS(ARCH_PFN_OFFSET), PFN_PHYS(max_low_pfn)); } -- 2.1.0 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter 2022-03-01 4:28 ` [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter Tiezhu Yang @ 2022-03-04 15:10 ` Thomas Bogendoerfer 2022-03-04 15:35 ` Thomas Bogendoerfer 0 siblings, 1 reply; 26+ messages in thread From: Thomas Bogendoerfer @ 2022-03-04 15:10 UTC (permalink / raw) To: Tiezhu Yang Cc: Mike Rapoport, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On Tue, Mar 01, 2022 at 12:28:58PM +0800, Tiezhu Yang wrote: > According to Documentation/admin-guide/kernel-parameters.txt, > the kernel command-line parameter mem= means "Force usage of > a specific amount of memory", but when add "mem=3G" to the > command-line, kernel boot hangs in sparse_init(). > > This commit is similar with the implementation of the other > archs such as arm64, powerpc and riscv, refactor the function > early_parse_mem() and then use memblock_enforce_memory_limit() > to limit the memory size. > > With this patch, when add "mem=3G" to the command-line, the > kernel boots successfully, we can see the following messages: unfortunately this patch would break platforms without memory detection, which simply use mem=32M for memory configuration. Not sure how many rely on this mechanism. If we can make sure nobody uses it, I'm fine with your patch. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter 2022-03-04 15:10 ` Thomas Bogendoerfer @ 2022-03-04 15:35 ` Thomas Bogendoerfer 2022-03-04 17:11 ` Maciej W. Rozycki 0 siblings, 1 reply; 26+ messages in thread From: Thomas Bogendoerfer @ 2022-03-04 15:35 UTC (permalink / raw) To: Tiezhu Yang Cc: Mike Rapoport, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On Fri, Mar 04, 2022 at 04:10:52PM +0100, Thomas Bogendoerfer wrote: > On Tue, Mar 01, 2022 at 12:28:58PM +0800, Tiezhu Yang wrote: > > According to Documentation/admin-guide/kernel-parameters.txt, > > the kernel command-line parameter mem= means "Force usage of > > a specific amount of memory", but when add "mem=3G" to the > > command-line, kernel boot hangs in sparse_init(). > > > > This commit is similar with the implementation of the other > > archs such as arm64, powerpc and riscv, refactor the function > > early_parse_mem() and then use memblock_enforce_memory_limit() > > to limit the memory size. > > > > With this patch, when add "mem=3G" to the command-line, the > > kernel boots successfully, we can see the following messages: > > unfortunately this patch would break platforms without memory detection, > which simply use mem=32M for memory configuration. Not sure how many > rely on this mechanism. If we can make sure nobody uses it, I'm fine > with your patch. maybe we could add a CONFIG option, which will be selected by platforms, which don't need/want this usermem thing. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter 2022-03-04 15:35 ` Thomas Bogendoerfer @ 2022-03-04 17:11 ` Maciej W. Rozycki 2022-03-05 13:13 ` Mike Rapoport 2022-03-07 16:29 ` Thomas Bogendoerfer 0 siblings, 2 replies; 26+ messages in thread From: Maciej W. Rozycki @ 2022-03-04 17:11 UTC (permalink / raw) To: Thomas Bogendoerfer Cc: Tiezhu Yang, Mike Rapoport, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On Fri, 4 Mar 2022, Thomas Bogendoerfer wrote: > > > With this patch, when add "mem=3G" to the command-line, the > > > kernel boots successfully, we can see the following messages: > > > > unfortunately this patch would break platforms without memory detection, > > which simply use mem=32M for memory configuration. Not sure how many > > rely on this mechanism. If we can make sure nobody uses it, I'm fine > > with your patch. > > maybe we could add a CONFIG option, which will be selected by > platforms, which don't need/want this usermem thing. FWIW I don't understand what the issue is here beyond that we have a bug that causes a system to hang when "mem=3G" is passed on the kernel command line. That is assuming that system does have contiguous RAM available for the kernel to use from address 0 up to 3GiB; otherwise it's a user error to tell the kernel it has that memory available (I did get bitten by that myself too): garbage in, garbage out. I think having a CONFIG option automatically selected to disable the ability to give a memory map override would handicap people in debugging their systems or working around firmware bugs, so I would rather be against it. Maciej ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter 2022-03-04 17:11 ` Maciej W. Rozycki @ 2022-03-05 13:13 ` Mike Rapoport 2022-03-07 16:29 ` Thomas Bogendoerfer 1 sibling, 0 replies; 26+ messages in thread From: Mike Rapoport @ 2022-03-05 13:13 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Thomas Bogendoerfer, Tiezhu Yang, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On Fri, Mar 04, 2022 at 05:11:44PM +0000, Maciej W. Rozycki wrote: > On Fri, 4 Mar 2022, Thomas Bogendoerfer wrote: > > > > > With this patch, when add "mem=3G" to the command-line, the > > > > kernel boots successfully, we can see the following messages: > > > > > > unfortunately this patch would break platforms without memory detection, > > > which simply use mem=32M for memory configuration. Not sure how many > > > rely on this mechanism. If we can make sure nobody uses it, I'm fine > > > with your patch. > > > > maybe we could add a CONFIG option, which will be selected by > > platforms, which don't need/want this usermem thing. > > FWIW I don't understand what the issue is here beyond that we have a bug > that causes a system to hang when "mem=3G" is passed on the kernel command > line. That is assuming that system does have contiguous RAM available for > the kernel to use from address 0 up to 3GiB; otherwise it's a user error > to tell the kernel it has that memory available (I did get bitten by that > myself too): garbage in, garbage out. This is exactly the case here because the system does not have contiguous RAM: [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000004000000-0x000000000effffff] [ 0.000000] node 0: [mem 0x0000000090200000-0x00000000ffffffff] [ 0.000000] node 0: [mem 0x0000000120000000-0x00000001653fffff] (from patch 3/4 in this series) I don't see what "bug" this patch is trying to fix. Is indeed possible to make MIPS' mem= behave like it does not arm64 and ppc, but that would break systems that use current semantics and I recall seeing some of OpenWRT machines using mem= to override memory map supplied by firmware. > Maciej -- Sincerely yours, Mike. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter 2022-03-04 17:11 ` Maciej W. Rozycki 2022-03-05 13:13 ` Mike Rapoport @ 2022-03-07 16:29 ` Thomas Bogendoerfer 2022-03-07 22:07 ` Mike Rapoport 1 sibling, 1 reply; 26+ messages in thread From: Thomas Bogendoerfer @ 2022-03-07 16:29 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Tiezhu Yang, Mike Rapoport, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On Fri, Mar 04, 2022 at 05:11:44PM +0000, Maciej W. Rozycki wrote: > On Fri, 4 Mar 2022, Thomas Bogendoerfer wrote: > > > > > With this patch, when add "mem=3G" to the command-line, the > > > > kernel boots successfully, we can see the following messages: > > > > > > unfortunately this patch would break platforms without memory detection, > > > which simply use mem=32M for memory configuration. Not sure how many > > > rely on this mechanism. If we can make sure nobody uses it, I'm fine > > > with your patch. > > > > maybe we could add a CONFIG option, which will be selected by > > platforms, which don't need/want this usermem thing. > > FWIW I don't understand what the issue is here beyond that we have a bug > that causes a system to hang when "mem=3G" is passed on the kernel command > line. That is assuming that system does have contiguous RAM available for > the kernel to use from address 0 up to 3GiB; otherwise it's a user error > to tell the kernel it has that memory available (I did get bitten by that > myself too): garbage in, garbage out. I did a quick test with an IP30: >> bootp(): ip=dhcp root=/dev/nfs console=ttyS0 mem=384M Setting $netaddr to 192.168.8.208 (from server ) Obtaining from server 9012640+181664 entry: 0xa800000020664a60 Linux version 5.17.0-rc3+ (tbogendoerfer@adalid) (mips64-linux-gnu-gcc (GCC) 6.1.1 20160621 (Red Hat Cross 6.1.1-2), GNU ld version 2.27-3.fc24) #155 SMP Mon Mar 7 13:12:01 CET 2022 ARCH: SGI-IP30 PROMLIB: ARC firmware Version 64 Revision 0 printk: bootconsole [early0] enabled CPU0 revision is: 00000934 (R10000) FPU revision is: 00000900 Detected 512MB of physical memory. User-defined physical RAM map overwrite Kernel sections are not in the memory maps IP30: Slot: 0, PrID: 00000934, PhyID: 0, VirtID: 0 IP30: Slot: 1, PrID: 00000934, PhyID: 1, VirtID: 1 IP30: Detected 2 CPU(s) present. Primary instruction cache 32kB, VIPT, 2-way, linesize 64 bytes. Primary data cache 32kB, 2-way, VIPT, no aliases, linesize 32 bytes Unified secondary cache 1024kB 2-way, linesize 128 bytes. Zone ranges: DMA32 [mem 0x0000000000000000-0x00000000ffffffff] Normal empty Movable zone start for each node Early memory node ranges node 0: [mem 0x0000000000000000-0x0000000017ffffff] node 0: [mem 0x0000000020004000-0x00000000208c7fff] Initmem setup node 0 [mem 0x0000000000000000-0x00000000208c7fff] after that it's dead (it doesn't have memory starting at 0x0). Most SGI systems will act broken with mem= in one way or another. And I already had the need to limit the amount of memory. > I think having a CONFIG option automatically selected to disable the > ability to give a memory map override would handicap people in debugging > their systems or working around firmware bugs, so I would rather be > against it. I'm thinking about a CONFIG option, which isn't user selectable, but selected via Kconfig only. But that would give to differents semantics for mem= So can I just limit amount of memory without interfering with normal memory detection ? Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter 2022-03-07 16:29 ` Thomas Bogendoerfer @ 2022-03-07 22:07 ` Mike Rapoport 2022-03-07 23:09 ` Maciej W. Rozycki 0 siblings, 1 reply; 26+ messages in thread From: Mike Rapoport @ 2022-03-07 22:07 UTC (permalink / raw) To: Thomas Bogendoerfer Cc: Maciej W. Rozycki, Tiezhu Yang, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On Mon, Mar 07, 2022 at 05:29:09PM +0100, Thomas Bogendoerfer wrote: > On Fri, Mar 04, 2022 at 05:11:44PM +0000, Maciej W. Rozycki wrote: > > On Fri, 4 Mar 2022, Thomas Bogendoerfer wrote: > > > > > > > With this patch, when add "mem=3G" to the command-line, the > > > > > kernel boots successfully, we can see the following messages: > > > > > > > > unfortunately this patch would break platforms without memory detection, > > > > which simply use mem=32M for memory configuration. Not sure how many > > > > rely on this mechanism. If we can make sure nobody uses it, I'm fine > > > > with your patch. > > > > > > maybe we could add a CONFIG option, which will be selected by > > > platforms, which don't need/want this usermem thing. > > > > FWIW I don't understand what the issue is here beyond that we have a bug > > that causes a system to hang when "mem=3G" is passed on the kernel command > > line. That is assuming that system does have contiguous RAM available for > > the kernel to use from address 0 up to 3GiB; otherwise it's a user error > > to tell the kernel it has that memory available (I did get bitten by that > > myself too): garbage in, garbage out. > > I did a quick test with an IP30: > > >> bootp(): ip=dhcp root=/dev/nfs console=ttyS0 mem=384M > Setting $netaddr to 192.168.8.208 (from server ) > Obtaining from server > 9012640+181664 entry: 0xa800000020664a60 > Linux version 5.17.0-rc3+ (tbogendoerfer@adalid) (mips64-linux-gnu-gcc (GCC) 6.1.1 20160621 (Red Hat Cross 6.1.1-2), GNU ld version 2.27-3.fc24) #155 SMP Mon Mar 7 13:12:01 CET 2022 > ARCH: SGI-IP30 > PROMLIB: ARC firmware Version 64 Revision 0 > printk: bootconsole [early0] enabled > CPU0 revision is: 00000934 (R10000) > FPU revision is: 00000900 > Detected 512MB of physical memory. > User-defined physical RAM map overwrite > Kernel sections are not in the memory maps > IP30: Slot: 0, PrID: 00000934, PhyID: 0, VirtID: 0 > IP30: Slot: 1, PrID: 00000934, PhyID: 1, VirtID: 1 > IP30: Detected 2 CPU(s) present. > Primary instruction cache 32kB, VIPT, 2-way, linesize 64 bytes. > Primary data cache 32kB, 2-way, VIPT, no aliases, linesize 32 bytes > Unified secondary cache 1024kB 2-way, linesize 128 bytes. > Zone ranges: > DMA32 [mem 0x0000000000000000-0x00000000ffffffff] > Normal empty > Movable zone start for each node > Early memory node ranges > node 0: [mem 0x0000000000000000-0x0000000017ffffff] > node 0: [mem 0x0000000020004000-0x00000000208c7fff] > Initmem setup node 0 [mem 0x0000000000000000-0x00000000208c7fff] > > after that it's dead (it doesn't have memory starting at 0x0). > Most SGI systems will act broken with mem= in one way or another. > And I already had the need to limit the amount of memory. > > > I think having a CONFIG option automatically selected to disable the > > ability to give a memory map override would handicap people in debugging > > their systems or working around firmware bugs, so I would rather be > > against it. > > I'm thinking about a CONFIG option, which isn't user selectable, but > selected via Kconfig only. But that would give to differents semantics > for mem= > > So can I just limit amount of memory without interfering with normal > memory detection ? Maybe it's better to add a new encoding to mem= that will have the semantics of limiting amount of memory? E.g. mem=384M@ would mean "only use 384M of memory that firmware reported" while mem=384M would mean "set memory to 0 - 384M" as it does now. I think it's fine to have this MIPS specific because there is anyway no consistency among architectures in mem= handling. > Thomas. > > -- > Crap can work. Given enough thrust pigs will fly, but it's not necessarily a > good idea. [ RFC1925, 2.3 ] -- Sincerely yours, Mike. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter 2022-03-07 22:07 ` Mike Rapoport @ 2022-03-07 23:09 ` Maciej W. Rozycki 0 siblings, 0 replies; 26+ messages in thread From: Maciej W. Rozycki @ 2022-03-07 23:09 UTC (permalink / raw) To: Mike Rapoport Cc: Thomas Bogendoerfer, Tiezhu Yang, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On Tue, 8 Mar 2022, Mike Rapoport wrote: > > So can I just limit amount of memory without interfering with normal > > memory detection ? > > Maybe it's better to add a new encoding to mem= that will have the semantics > of limiting amount of memory? > > E.g. > > mem=384M@ > > would mean "only use 384M of memory that firmware reported" while > > mem=384M would mean "set memory to 0 - 384M" as it does now. I think you're going in the right direction, we'd just need to sort out the most reasonable syntax for the new semantics; `mem=384M@' just seems too analogous to me to `mem=384M@0'. Maybe `mem=384M-'? NB that would have to work with the existing overrides, for e.g.: `mem=192M@0 mem=192M@256M mem=384M-' to produce the following memory ranges available for use: Normal [mem 0x0000000000000000-0x000000000bffffff] Normal [mem 0x0000000010000000-0x0000000017ffffff] (so that you can paste the final cap at some command prompt and still have earlier parameters respected that may have been passed by the firmware or bootloader, or built in). Maciej ^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH v4 2/4] memblock: Introduce memblock_mem_range_remove_map() 2022-03-01 4:28 [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter Tiezhu Yang 2022-03-01 4:28 ` [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter Tiezhu Yang @ 2022-03-01 4:28 ` Tiezhu Yang 2022-03-01 4:29 ` [PATCH v4 3/4] MIPS: Refactor early_parse_memmap() to fix memmap= parameter Tiezhu Yang ` (2 subsequent siblings) 4 siblings, 0 replies; 26+ messages in thread From: Tiezhu Yang @ 2022-03-01 4:28 UTC (permalink / raw) To: Thomas Bogendoerfer, Mike Rapoport, Andrew Morton Cc: Xuefeng Li, linux-mips, linux-mm, linux-kernel This is preparation for supporting memmap=limit@base parameter, no functionality change. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> --- include/linux/memblock.h | 1 + mm/memblock.c | 9 +++++++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/include/linux/memblock.h b/include/linux/memblock.h index 50ad196..e558d2c 100644 --- a/include/linux/memblock.h +++ b/include/linux/memblock.h @@ -482,6 +482,7 @@ phys_addr_t memblock_end_of_DRAM(void); void memblock_enforce_memory_limit(phys_addr_t memory_limit); void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size); void memblock_mem_limit_remove_map(phys_addr_t limit); +void memblock_mem_range_remove_map(phys_addr_t base, phys_addr_t limit); bool memblock_is_memory(phys_addr_t addr); bool memblock_is_map_memory(phys_addr_t addr); bool memblock_is_region_memory(phys_addr_t base, phys_addr_t size); diff --git a/mm/memblock.c b/mm/memblock.c index 1018e50..2476d15d 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -1723,7 +1723,7 @@ void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size) base + size, PHYS_ADDR_MAX); } -void __init memblock_mem_limit_remove_map(phys_addr_t limit) +void __init memblock_mem_range_remove_map(phys_addr_t base, phys_addr_t limit) { phys_addr_t max_addr; @@ -1736,7 +1736,12 @@ void __init memblock_mem_limit_remove_map(phys_addr_t limit) if (max_addr == PHYS_ADDR_MAX) return; - memblock_cap_memory_range(0, max_addr); + memblock_cap_memory_range(base, max_addr); +} + +void __init memblock_mem_limit_remove_map(phys_addr_t limit) +{ + memblock_mem_range_remove_map(0, limit); } static int __init_memblock memblock_search(struct memblock_type *type, phys_addr_t addr) -- 2.1.0 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH v4 3/4] MIPS: Refactor early_parse_memmap() to fix memmap= parameter 2022-03-01 4:28 [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter Tiezhu Yang 2022-03-01 4:28 ` [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter Tiezhu Yang 2022-03-01 4:28 ` [PATCH v4 2/4] memblock: Introduce memblock_mem_range_remove_map() Tiezhu Yang @ 2022-03-01 4:29 ` Tiezhu Yang 2022-03-01 4:29 ` [PATCH v4 4/4] MIPS: Remove not used variable usermem Tiezhu Yang 2022-03-01 9:55 ` [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter Mike Rapoport 4 siblings, 0 replies; 26+ messages in thread From: Tiezhu Yang @ 2022-03-01 4:29 UTC (permalink / raw) To: Thomas Bogendoerfer, Mike Rapoport, Andrew Morton Cc: Xuefeng Li, linux-mips, linux-mm, linux-kernel According to Documentation/admin-guide/kernel-parameters.txt, the kernel command-line parameter memmap= means "Force usage of a specific region of memory", but when add "memmap=3G@64M" to the command-line, kernel boot hangs in sparse_init(). In order to support memmap=limit@base, refactor the function early_parse_memmap() and then use memblock_mem_range_remove_map() to limit the memory region. With this patch, when add "memmap=3G@64M" to the command-line, the kernel boots successfully, we can see the following messages: [ 0.000000] Memory limited to 64MB-3136MB ... [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000004000000-0x000000000effffff] [ 0.000000] node 0: [mem 0x0000000090200000-0x00000000ffffffff] [ 0.000000] node 0: [mem 0x0000000120000000-0x00000001653fffff] ... [ 0.000000] Memory: 3070816K/3147776K available (...) When add "memmap=128M@64M nr_cpus=1 init 3" to the command-line, the kernel also boots successfully, we can see the following messages: [ 0.000000] Memory limited to 64MB-192MB ... [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000004000000-0x000000000c1fffff] ... [ 0.000000] Memory: 95312K/133120K available (...) After login, the output of free command is consistent with the above log. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> --- arch/mips/kernel/setup.c | 40 ++++++++++++++++++++++++---------------- 1 file changed, 24 insertions(+), 16 deletions(-) diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c index 50396ba..30c7d95 100644 --- a/arch/mips/kernel/setup.c +++ b/arch/mips/kernel/setup.c @@ -340,6 +340,7 @@ static void __init bootmem_init(void) static int usermem __initdata; static phys_addr_t memory_limit; +static phys_addr_t memory_base; static int __init early_parse_mem(char *p) { @@ -356,7 +357,6 @@ early_param("mem", early_parse_mem); static int __init early_parse_memmap(char *p) { char *oldp; - u64 start_at, mem_size; if (!p) return -EINVAL; @@ -367,30 +367,38 @@ static int __init early_parse_memmap(char *p) } oldp = p; - mem_size = memparse(p, &p); + memory_limit = memparse(p, &p) & PAGE_MASK; if (p == oldp) return -EINVAL; if (*p == '@') { - start_at = memparse(p+1, &p); - memblock_add(start_at, mem_size); + memory_base = memparse(p + 1, &p) & PAGE_MASK; + } else if (*p == '$') { + memory_base = memparse(p+1, &p) & PAGE_MASK; + memblock_reserve(memory_base, memory_limit); + pr_notice("Memory reserved to %lluMB-%lluMB\n", + (u64)memory_base >> 20, (u64)(memory_base + memory_limit) >> 20); + memory_base = 0; + memory_limit = 0; + return 0; } else if (*p == '#') { - pr_err("\"memmap=nn#ss\" (force ACPI data) invalid on MIPS\n"); + pr_err("\"memmap=nn#ss\" invalid on MIPS\n"); + memory_limit = 0; + return -EINVAL; + } else if (*p == '!') { + pr_err("\"memmap=nn!ss\" invalid on MIPS\n"); + memory_limit = 0; return -EINVAL; - } else if (*p == '$') { - start_at = memparse(p+1, &p); - memblock_add(start_at, mem_size); - memblock_reserve(start_at, mem_size); } else { - pr_err("\"memmap\" invalid format!\n"); + pr_err("Unrecognized memmap syntax: %s\n", p); + memory_limit = 0; return -EINVAL; } - if (*p == '\0') { - usermem = 1; - return 0; - } else - return -EINVAL; + pr_notice("Memory limited to %lluMB-%lluMB\n", + (u64)memory_base >> 20, (u64)(memory_base + memory_limit) >> 20); + + return *p == '\0' ? 0 : -EINVAL; } early_param("memmap", early_parse_memmap); @@ -667,7 +675,7 @@ static void __init arch_mem_init(char **cmdline_p) __pa_symbol(&__nosave_end) - __pa_symbol(&__nosave_begin)); /* Limit the memory. */ - memblock_enforce_memory_limit(memory_limit); + memblock_mem_range_remove_map(memory_base, memory_limit); memblock_allow_resize(); early_memtest(PFN_PHYS(ARCH_PFN_OFFSET), PFN_PHYS(max_low_pfn)); -- 2.1.0 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH v4 4/4] MIPS: Remove not used variable usermem 2022-03-01 4:28 [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter Tiezhu Yang ` (2 preceding siblings ...) 2022-03-01 4:29 ` [PATCH v4 3/4] MIPS: Refactor early_parse_memmap() to fix memmap= parameter Tiezhu Yang @ 2022-03-01 4:29 ` Tiezhu Yang 2022-03-01 9:55 ` [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter Mike Rapoport 4 siblings, 0 replies; 26+ messages in thread From: Tiezhu Yang @ 2022-03-01 4:29 UTC (permalink / raw) To: Thomas Bogendoerfer, Mike Rapoport, Andrew Morton Cc: Xuefeng Li, linux-mips, linux-mm, linux-kernel Now, the variable usermem is not used any more, just remove it. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> --- arch/mips/kernel/setup.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c index 30c7d95..8f900f8 100644 --- a/arch/mips/kernel/setup.c +++ b/arch/mips/kernel/setup.c @@ -338,7 +338,6 @@ static void __init bootmem_init(void) #endif /* CONFIG_SGI_IP27 */ -static int usermem __initdata; static phys_addr_t memory_limit; static phys_addr_t memory_base; @@ -628,10 +627,6 @@ static void __init arch_mem_init(char **cmdline_p) *cmdline_p = command_line; parse_early_param(); - - if (usermem) - pr_info("User-defined physical RAM map overwrite\n"); - check_kernel_sections_mem(); early_init_fdt_reserve_self(); -- 2.1.0 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter 2022-03-01 4:28 [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter Tiezhu Yang ` (3 preceding siblings ...) 2022-03-01 4:29 ` [PATCH v4 4/4] MIPS: Remove not used variable usermem Tiezhu Yang @ 2022-03-01 9:55 ` Mike Rapoport 2022-03-01 11:51 ` Tiezhu Yang 4 siblings, 1 reply; 26+ messages in thread From: Mike Rapoport @ 2022-03-01 9:55 UTC (permalink / raw) To: Tiezhu Yang Cc: Thomas Bogendoerfer, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel Hi, On Tue, Mar 01, 2022 at 12:28:57PM +0800, Tiezhu Yang wrote: > In the current code, the kernel command-line parameter mem= and memmap= > can not work well on MIPS, this patchset refactors the related code to > fix them. > > For kdump on MIPS, if the users want to limit the memory region for the > capture kernel to avoid corrupting the memory image of the panic kernel, > use the parameter memmap=limit@base is the proper way, I will submit a > patch to use memmap=limit@base for kexec-tools after this patchset is > applied. Sorry, apparently I misread the prevoius version. What's wrong with the current implementation of mem=limit@base for the kdump case? > v4: Fix some build warnings reported by kernel test robot > > v3: Modify patch #3 to maintain compatibility for memmap=limit{$,#,!}base, > commented by Mike Rapoport, thank you > > v2: Add some new patches to support memmap=limit@base > > Tiezhu Yang (4): > MIPS: Refactor early_parse_mem() to fix mem= parameter > memblock: Introduce memblock_mem_range_remove_map() > MIPS: Refactor early_parse_memmap() to fix memmap= parameter > MIPS: Remove not used variable usermem > > arch/mips/kernel/setup.c | 69 ++++++++++++++++++++++-------------------------- > include/linux/memblock.h | 1 + > mm/memblock.c | 9 +++++-- > 3 files changed, 40 insertions(+), 39 deletions(-) > > -- > 2.1.0 > -- Sincerely yours, Mike. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter 2022-03-01 9:55 ` [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter Mike Rapoport @ 2022-03-01 11:51 ` Tiezhu Yang 2022-03-01 14:31 ` Mike Rapoport 0 siblings, 1 reply; 26+ messages in thread From: Tiezhu Yang @ 2022-03-01 11:51 UTC (permalink / raw) To: Mike Rapoport Cc: Thomas Bogendoerfer, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On 03/01/2022 05:55 PM, Mike Rapoport wrote: > Hi, > > On Tue, Mar 01, 2022 at 12:28:57PM +0800, Tiezhu Yang wrote: >> In the current code, the kernel command-line parameter mem= and memmap= >> can not work well on MIPS, this patchset refactors the related code to >> fix them. >> >> For kdump on MIPS, if the users want to limit the memory region for the >> capture kernel to avoid corrupting the memory image of the panic kernel, >> use the parameter memmap=limit@base is the proper way, I will submit a >> patch to use memmap=limit@base for kexec-tools after this patchset is >> applied. > > Sorry, apparently I misread the prevoius version. > What's wrong with the current implementation of mem=limit@base for the > kdump case? In the current code, without this patchset, kernel boot hangs when add mem=3G, mem=3G@64M or memmap=3G@64M to the command-line, it means that the parameter mem= and memmap= have bug on mips. Thanks, Tiezhu > >> v4: Fix some build warnings reported by kernel test robot >> >> v3: Modify patch #3 to maintain compatibility for memmap=limit{$,#,!}base, >> commented by Mike Rapoport, thank you >> >> v2: Add some new patches to support memmap=limit@base >> >> Tiezhu Yang (4): >> MIPS: Refactor early_parse_mem() to fix mem= parameter >> memblock: Introduce memblock_mem_range_remove_map() >> MIPS: Refactor early_parse_memmap() to fix memmap= parameter >> MIPS: Remove not used variable usermem >> >> arch/mips/kernel/setup.c | 69 ++++++++++++++++++++++-------------------------- >> include/linux/memblock.h | 1 + >> mm/memblock.c | 9 +++++-- >> 3 files changed, 40 insertions(+), 39 deletions(-) >> >> -- >> 2.1.0 >> > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter 2022-03-01 11:51 ` Tiezhu Yang @ 2022-03-01 14:31 ` Mike Rapoport 2022-03-02 1:50 ` Tiezhu Yang 0 siblings, 1 reply; 26+ messages in thread From: Mike Rapoport @ 2022-03-01 14:31 UTC (permalink / raw) To: Tiezhu Yang Cc: Thomas Bogendoerfer, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On Tue, Mar 01, 2022 at 07:51:23PM +0800, Tiezhu Yang wrote: > > > On 03/01/2022 05:55 PM, Mike Rapoport wrote: > > Hi, > > > > On Tue, Mar 01, 2022 at 12:28:57PM +0800, Tiezhu Yang wrote: > > > In the current code, the kernel command-line parameter mem= and memmap= > > > can not work well on MIPS, this patchset refactors the related code to > > > fix them. > > > > > > For kdump on MIPS, if the users want to limit the memory region for the > > > capture kernel to avoid corrupting the memory image of the panic kernel, > > > use the parameter memmap=limit@base is the proper way, I will submit a > > > patch to use memmap=limit@base for kexec-tools after this patchset is > > > applied. > > > > Sorry, apparently I misread the prevoius version. > > What's wrong with the current implementation of mem=limit@base for the > > kdump case? > > In the current code, without this patchset, kernel boot hangs when add > mem=3G, mem=3G@64M or memmap=3G@64M to the command-line, it means that > the parameter mem= and memmap= have bug on mips. I can see how mem=3G may be wrong when the memory does not start at 0, but it seems to do the right thing of mem=3G@64M. Do you see system hangs with mem=3G@64M? Do you have the logs before the hang? As for memmap= option, it does not specify the memory map but rather alters the memory map passed by the firmware. Particularity in MIPS implementation it allows to add a single range of available or reserved memory. AFAIU, for the kdump use-case mem=X@Y should suffice. > Thanks, > Tiezhu > > > > > > v4: Fix some build warnings reported by kernel test robot > > > > > > v3: Modify patch #3 to maintain compatibility for memmap=limit{$,#,!}base, > > > commented by Mike Rapoport, thank you > > > > > > v2: Add some new patches to support memmap=limit@base > > > > > > Tiezhu Yang (4): > > > MIPS: Refactor early_parse_mem() to fix mem= parameter > > > memblock: Introduce memblock_mem_range_remove_map() > > > MIPS: Refactor early_parse_memmap() to fix memmap= parameter > > > MIPS: Remove not used variable usermem > > > > > > arch/mips/kernel/setup.c | 69 ++++++++++++++++++++++-------------------------- > > > include/linux/memblock.h | 1 + > > > mm/memblock.c | 9 +++++-- > > > 3 files changed, 40 insertions(+), 39 deletions(-) > > > > > > -- > > > 2.1.0 > > > > > > -- Sincerely yours, Mike. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter 2022-03-01 14:31 ` Mike Rapoport @ 2022-03-02 1:50 ` Tiezhu Yang 2022-03-02 8:03 ` Mike Rapoport 2022-03-04 17:05 ` Maciej W. Rozycki 0 siblings, 2 replies; 26+ messages in thread From: Tiezhu Yang @ 2022-03-02 1:50 UTC (permalink / raw) To: Mike Rapoport Cc: Thomas Bogendoerfer, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On 03/01/2022 10:31 PM, Mike Rapoport wrote: > On Tue, Mar 01, 2022 at 07:51:23PM +0800, Tiezhu Yang wrote: >> >> >> On 03/01/2022 05:55 PM, Mike Rapoport wrote: >>> Hi, >>> >>> On Tue, Mar 01, 2022 at 12:28:57PM +0800, Tiezhu Yang wrote: >>>> In the current code, the kernel command-line parameter mem= and memmap= >>>> can not work well on MIPS, this patchset refactors the related code to >>>> fix them. >>>> >>>> For kdump on MIPS, if the users want to limit the memory region for the >>>> capture kernel to avoid corrupting the memory image of the panic kernel, >>>> use the parameter memmap=limit@base is the proper way, I will submit a >>>> patch to use memmap=limit@base for kexec-tools after this patchset is >>>> applied. >>> >>> Sorry, apparently I misread the prevoius version. >>> What's wrong with the current implementation of mem=limit@base for the >>> kdump case? >> >> In the current code, without this patchset, kernel boot hangs when add >> mem=3G, mem=3G@64M or memmap=3G@64M to the command-line, it means that >> the parameter mem= and memmap= have bug on mips. > > I can see how mem=3G may be wrong when the memory does not start at 0, but > it seems to do the right thing of mem=3G@64M. > > Do you see system hangs with mem=3G@64M? Yes. > > Do you have the logs before the hang? Here are the logs: [ 0.000000] Linux version 5.17.0-rc3+ (loongson@linux) (gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-6), GNU ld version 2.28-13.fc21.loongson.6) #1 SMP PREEMPT Wed Mar 2 09:07:39 CST 2022 [ 0.000000] CpuClock = 1800000000 [ 0.000000] The bridge chip is LS7A [ 0.000000] CP0_Config3: CP0 16.3 (0xdc8030a0) [ 0.000000] CP0_PageGrain: CP0 5.1 (0x28000000) [ 0.000000] NUMA: Discovered 4 cpus on 1 nodes [ 0.000000] Node0: mem_type:1, mem_start:0x200000, mem_size:0xee MB [ 0.000000] start_pfn:0x80, end_pfn:0x3c00, num_physpages:0x3b80 [ 0.000000] Node0: mem_type:2, mem_start:0x90200000, mem_size:0x6fe MB [ 0.000000] start_pfn:0x24080, end_pfn:0x40000, num_physpages:0x1fb00 [ 0.000000] Node0: mem_type:2, mem_start:0x120000000, mem_size:0x1600 MB [ 0.000000] start_pfn:0x48000, end_pfn:0xa0000, num_physpages:0x77b00 [ 0.000000] Node0's addrspace_offset is 0x0 [ 0.000000] Node0: start_pfn=0x80, end_pfn=0xa0000 [ 0.000000] NUMA: set cpumask cpu 0 on node 0 [ 0.000000] NUMA: set cpumask cpu 1 on node 0 [ 0.000000] NUMA: set cpumask cpu 2 on node 0 [ 0.000000] NUMA: set cpumask cpu 3 on node 0 [ 0.000000] printk: bootconsole [early0] enabled [ 0.000000] CPU0 revision is: 0014c001 (ICT Loongson-3) [ 0.000000] FPU revision is: 00f70501 [ 0.000000] MSA revision is: 00060140 [ 0.000000] OF: fdt: No chosen node found, continuing without [ 0.000000] MIPS: machine is loongson,loongson64g-4core-ls7a [ 0.000000] User-defined physical RAM map overwrite [ 0.000000] Kernel sections are not in the memory maps [ 0.000000] Initrd not found or empty - disabling initrd > > As for memmap= option, it does not specify the memory map but rather alters > the memory map passed by the firmware. Particularity in MIPS implementation > it allows to add a single range of available or reserved memory. > > AFAIU, for the kdump use-case mem=X@Y should suffice. We can modify some code to make mem=X@Y work well, but according to Documentation/admin-guide/kernel-parameters.txt, the common way is mem=X and memmap=X@Y, so mem=X@Y for mips seems odd, the intention of this patchset is to make mem= and memmap= work well and consistent with the other archs. Thanks, Tiezhu > >> Thanks, >> Tiezhu >> >>> >>>> v4: Fix some build warnings reported by kernel test robot >>>> >>>> v3: Modify patch #3 to maintain compatibility for memmap=limit{$,#,!}base, >>>> commented by Mike Rapoport, thank you >>>> >>>> v2: Add some new patches to support memmap=limit@base >>>> >>>> Tiezhu Yang (4): >>>> MIPS: Refactor early_parse_mem() to fix mem= parameter >>>> memblock: Introduce memblock_mem_range_remove_map() >>>> MIPS: Refactor early_parse_memmap() to fix memmap= parameter >>>> MIPS: Remove not used variable usermem >>>> >>>> arch/mips/kernel/setup.c | 69 ++++++++++++++++++++++-------------------------- >>>> include/linux/memblock.h | 1 + >>>> mm/memblock.c | 9 +++++-- >>>> 3 files changed, 40 insertions(+), 39 deletions(-) >>>> >>>> -- >>>> 2.1.0 >>>> >>> >> > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter 2022-03-02 1:50 ` Tiezhu Yang @ 2022-03-02 8:03 ` Mike Rapoport 2022-03-02 9:28 ` Tiezhu Yang 2022-03-04 17:05 ` Maciej W. Rozycki 1 sibling, 1 reply; 26+ messages in thread From: Mike Rapoport @ 2022-03-02 8:03 UTC (permalink / raw) To: Tiezhu Yang Cc: Thomas Bogendoerfer, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On Wed, Mar 02, 2022 at 09:50:49AM +0800, Tiezhu Yang wrote: > > > On 03/01/2022 10:31 PM, Mike Rapoport wrote: > > On Tue, Mar 01, 2022 at 07:51:23PM +0800, Tiezhu Yang wrote: > > > > > > > > > On 03/01/2022 05:55 PM, Mike Rapoport wrote: > > > > Hi, > > > > > > > > On Tue, Mar 01, 2022 at 12:28:57PM +0800, Tiezhu Yang wrote: > > > > > In the current code, the kernel command-line parameter mem= and memmap= > > > > > can not work well on MIPS, this patchset refactors the related code to > > > > > fix them. > > > > > > > > > > For kdump on MIPS, if the users want to limit the memory region for the > > > > > capture kernel to avoid corrupting the memory image of the panic kernel, > > > > > use the parameter memmap=limit@base is the proper way, I will submit a > > > > > patch to use memmap=limit@base for kexec-tools after this patchset is > > > > > applied. > > > > > > > > Sorry, apparently I misread the prevoius version. > > > > What's wrong with the current implementation of mem=limit@base for the > > > > kdump case? > > > > > > In the current code, without this patchset, kernel boot hangs when add > > > mem=3G, mem=3G@64M or memmap=3G@64M to the command-line, it means that > > > the parameter mem= and memmap= have bug on mips. > > > > I can see how mem=3G may be wrong when the memory does not start at 0, but > > it seems to do the right thing of mem=3G@64M. > > > > Do you see system hangs with mem=3G@64M? > > Yes. > > > > > Do you have the logs before the hang? > > Here are the logs: > > [ 0.000000] Linux version 5.17.0-rc3+ (loongson@linux) (gcc (GCC) 7.3.1 > 20180303 (Red Hat 7.3.1-6), GNU ld version 2.28-13.fc21.loongson.6) #1 SMP > PREEMPT Wed Mar 2 09:07:39 CST 2022 > [ 0.000000] CpuClock = 1800000000 > [ 0.000000] The bridge chip is LS7A > [ 0.000000] CP0_Config3: CP0 16.3 (0xdc8030a0) > [ 0.000000] CP0_PageGrain: CP0 5.1 (0x28000000) > [ 0.000000] NUMA: Discovered 4 cpus on 1 nodes > [ 0.000000] Node0: mem_type:1, mem_start:0x200000, mem_size:0xee MB > [ 0.000000] start_pfn:0x80, end_pfn:0x3c00, num_physpages:0x3b80 > [ 0.000000] Node0: mem_type:2, mem_start:0x90200000, mem_size:0x6fe MB > [ 0.000000] start_pfn:0x24080, end_pfn:0x40000, > num_physpages:0x1fb00 > [ 0.000000] Node0: mem_type:2, mem_start:0x120000000, mem_size:0x1600 MB > [ 0.000000] start_pfn:0x48000, end_pfn:0xa0000, > num_physpages:0x77b00 > [ 0.000000] Node0's addrspace_offset is 0x0 > [ 0.000000] Node0: start_pfn=0x80, end_pfn=0xa0000 > [ 0.000000] NUMA: set cpumask cpu 0 on node 0 > [ 0.000000] NUMA: set cpumask cpu 1 on node 0 > [ 0.000000] NUMA: set cpumask cpu 2 on node 0 > [ 0.000000] NUMA: set cpumask cpu 3 on node 0 > [ 0.000000] printk: bootconsole [early0] enabled > [ 0.000000] CPU0 revision is: 0014c001 (ICT Loongson-3) > [ 0.000000] FPU revision is: 00f70501 > [ 0.000000] MSA revision is: 00060140 > [ 0.000000] OF: fdt: No chosen node found, continuing without > [ 0.000000] MIPS: machine is loongson,loongson64g-4core-ls7a > [ 0.000000] User-defined physical RAM map overwrite > [ 0.000000] Kernel sections are not in the memory maps > [ 0.000000] Initrd not found or empty - disabling initrd Can you please also send the log with "memblock=debug" added to the kernel command line? > > As for memmap= option, it does not specify the memory map but rather alters > > the memory map passed by the firmware. Particularity in MIPS implementation > > it allows to add a single range of available or reserved memory. > > > > AFAIU, for the kdump use-case mem=X@Y should suffice. > > We can modify some code to make mem=X@Y work well, > but according to Documentation/admin-guide/kernel-parameters.txt, > the common way is mem=X and memmap=X@Y, so mem=X@Y for mips seems > odd, the intention of this patchset is to make mem= and memmap= > work well and consistent with the other archs. These options are anyway not consistent on different architectures. arm, mips and x86 implement mem= one way and arm64, powerpc and riscv in another so there is no common way to use mem=. Your changes will break the existing systems that use mem= and memmap= options because they change the semantics of their MIPS implementation. For kexec/kdump use-cases modern architectures usually do not pass mem= but rather prepare the memory map for the kexeced kernel to use. I believe this would be the right solution. > Thanks, > Tiezhu > > > > > > Thanks, > > > Tiezhu > > > > > > > > > > > > v4: Fix some build warnings reported by kernel test robot > > > > > > > > > > v3: Modify patch #3 to maintain compatibility for memmap=limit{$,#,!}base, > > > > > commented by Mike Rapoport, thank you > > > > > > > > > > v2: Add some new patches to support memmap=limit@base > > > > > > > > > > Tiezhu Yang (4): > > > > > MIPS: Refactor early_parse_mem() to fix mem= parameter > > > > > memblock: Introduce memblock_mem_range_remove_map() > > > > > MIPS: Refactor early_parse_memmap() to fix memmap= parameter > > > > > MIPS: Remove not used variable usermem > > > > > > > > > > arch/mips/kernel/setup.c | 69 ++++++++++++++++++++++-------------------------- > > > > > include/linux/memblock.h | 1 + > > > > > mm/memblock.c | 9 +++++-- > > > > > 3 files changed, 40 insertions(+), 39 deletions(-) > > > > > > > > > > -- > > > > > 2.1.0 > > > > > > > > > > > > > > > -- Sincerely yours, Mike. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter 2022-03-02 8:03 ` Mike Rapoport @ 2022-03-02 9:28 ` Tiezhu Yang 2022-03-02 12:50 ` Mike Rapoport 0 siblings, 1 reply; 26+ messages in thread From: Tiezhu Yang @ 2022-03-02 9:28 UTC (permalink / raw) To: Mike Rapoport Cc: Thomas Bogendoerfer, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On 03/02/2022 04:03 PM, Mike Rapoport wrote: > On Wed, Mar 02, 2022 at 09:50:49AM +0800, Tiezhu Yang wrote: >> >> >> On 03/01/2022 10:31 PM, Mike Rapoport wrote: >>> On Tue, Mar 01, 2022 at 07:51:23PM +0800, Tiezhu Yang wrote: >>>> >>>> >>>> On 03/01/2022 05:55 PM, Mike Rapoport wrote: >>>>> Hi, >>>>> >>>>> On Tue, Mar 01, 2022 at 12:28:57PM +0800, Tiezhu Yang wrote: >>>>>> In the current code, the kernel command-line parameter mem= and memmap= >>>>>> can not work well on MIPS, this patchset refactors the related code to >>>>>> fix them. >>>>>> >>>>>> For kdump on MIPS, if the users want to limit the memory region for the >>>>>> capture kernel to avoid corrupting the memory image of the panic kernel, >>>>>> use the parameter memmap=limit@base is the proper way, I will submit a >>>>>> patch to use memmap=limit@base for kexec-tools after this patchset is >>>>>> applied. >>>>> >>>>> Sorry, apparently I misread the prevoius version. >>>>> What's wrong with the current implementation of mem=limit@base for the >>>>> kdump case? >>>> >>>> In the current code, without this patchset, kernel boot hangs when add >>>> mem=3G, mem=3G@64M or memmap=3G@64M to the command-line, it means that >>>> the parameter mem= and memmap= have bug on mips. >>> >>> I can see how mem=3G may be wrong when the memory does not start at 0, but >>> it seems to do the right thing of mem=3G@64M. >>> >>> Do you see system hangs with mem=3G@64M? >> >> Yes. >> >>> >>> Do you have the logs before the hang? >> >> Here are the logs: >> >> [ 0.000000] Linux version 5.17.0-rc3+ (loongson@linux) (gcc (GCC) 7.3.1 >> 20180303 (Red Hat 7.3.1-6), GNU ld version 2.28-13.fc21.loongson.6) #1 SMP >> PREEMPT Wed Mar 2 09:07:39 CST 2022 >> [ 0.000000] CpuClock = 1800000000 >> [ 0.000000] The bridge chip is LS7A >> [ 0.000000] CP0_Config3: CP0 16.3 (0xdc8030a0) >> [ 0.000000] CP0_PageGrain: CP0 5.1 (0x28000000) >> [ 0.000000] NUMA: Discovered 4 cpus on 1 nodes >> [ 0.000000] Node0: mem_type:1, mem_start:0x200000, mem_size:0xee MB >> [ 0.000000] start_pfn:0x80, end_pfn:0x3c00, num_physpages:0x3b80 >> [ 0.000000] Node0: mem_type:2, mem_start:0x90200000, mem_size:0x6fe MB >> [ 0.000000] start_pfn:0x24080, end_pfn:0x40000, >> num_physpages:0x1fb00 >> [ 0.000000] Node0: mem_type:2, mem_start:0x120000000, mem_size:0x1600 MB >> [ 0.000000] start_pfn:0x48000, end_pfn:0xa0000, >> num_physpages:0x77b00 >> [ 0.000000] Node0's addrspace_offset is 0x0 >> [ 0.000000] Node0: start_pfn=0x80, end_pfn=0xa0000 >> [ 0.000000] NUMA: set cpumask cpu 0 on node 0 >> [ 0.000000] NUMA: set cpumask cpu 1 on node 0 >> [ 0.000000] NUMA: set cpumask cpu 2 on node 0 >> [ 0.000000] NUMA: set cpumask cpu 3 on node 0 >> [ 0.000000] printk: bootconsole [early0] enabled >> [ 0.000000] CPU0 revision is: 0014c001 (ICT Loongson-3) >> [ 0.000000] FPU revision is: 00f70501 >> [ 0.000000] MSA revision is: 00060140 >> [ 0.000000] OF: fdt: No chosen node found, continuing without >> [ 0.000000] MIPS: machine is loongson,loongson64g-4core-ls7a >> [ 0.000000] User-defined physical RAM map overwrite >> [ 0.000000] Kernel sections are not in the memory maps >> [ 0.000000] Initrd not found or empty - disabling initrd > > Can you please also send the log with "memblock=debug" added to the kernel > command line? [ 0.000000] Linux version 5.17.0-rc3+ (loongson@linux) (gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-6), GNU ld version 2.28-13.fc21.loongson.6) #1 SMP PREEMPT Wed Mar 2 09:07:39 CST 2022 [ 0.000000] CpuClock = 1800000000 [ 0.000000] The bridge chip is LS7A [ 0.000000] CP0_Config3: CP0 16.3 (0xdc8030a0) [ 0.000000] CP0_PageGrain: CP0 5.1 (0x28000000) [ 0.000000] NUMA: Discovered 4 cpus on 1 nodes [ 0.000000] Node0: mem_type:1, mem_start:0x200000, mem_size:0xee MB [ 0.000000] start_pfn:0x80, end_pfn:0x3c00, num_physpages:0x3b80 [ 0.000000] Node0: mem_type:2, mem_start:0x90200000, mem_size:0x6fe MB [ 0.000000] start_pfn:0x24080, end_pfn:0x40000, num_physpages:0x1fb00 [ 0.000000] Node0: mem_type:2, mem_start:0x120000000, mem_size:0x1600 MB [ 0.000000] start_pfn:0x48000, end_pfn:0xa0000, num_physpages:0x77b00 [ 0.000000] Node0's addrspace_offset is 0x0 [ 0.000000] Node0: start_pfn=0x80, end_pfn=0xa0000 [ 0.000000] NUMA: set cpumask cpu 0 on node 0 [ 0.000000] NUMA: set cpumask cpu 1 on node 0 [ 0.000000] NUMA: set cpumask cpu 2 on node 0 [ 0.000000] NUMA: set cpumask cpu 3 on node 0 [ 0.000000] printk: bootconsole [early0] enabled [ 0.000000] CPU0 revision is: 0014c001 (ICT Loongson-3) [ 0.000000] FPU revision is: 00f70501 [ 0.000000] MSA revision is: 00060140 [ 0.000000] OF: fdt: No chosen node found, continuing without [ 0.000000] MIPS: machine is loongson,loongson64g-4core-ls7a [ 0.000000] User-defined physical RAM map overwrite [ 0.000000] Kernel sections are not in the memory maps [ 0.000000] memblock_add: [0x0000000000200000-0x000000000231185f] setup_arch+0x140/0x794 [ 0.000000] memblock_reserve: [0x0000000001260520-0x0000000001262560] setup_arch+0x148/0x794 [ 0.000000] Initrd not found or empty - disabling initrd [ 0.000000] memblock_alloc_try_nid: 8257 bytes align=0x40 nid=-1 from=0x0000000000000000 max_addr=0x0000000000000000 early_init_dt_alloc_memory_arch+0x30/0x60 [ 0.000000] memblock_reserve: [0x0000000004000000-0x0000000004002040] memblock_alloc_range_nid+0xf0/0x178 [ 0.000000] memblock_alloc_try_nid: 37972 bytes align=0x8 nid=-1 from=0x0000000000000000 max_addr=0x0000000000000000 early_init_dt_alloc_memory_arch+0x30/0x60 [ 0.000000] memblock_reserve: [0x0000000004002048-0x000000000400b49b] memblock_alloc_range_nid+0xf0/0x178 > >>> As for memmap= option, it does not specify the memory map but rather alters >>> the memory map passed by the firmware. Particularity in MIPS implementation >>> it allows to add a single range of available or reserved memory. >>> >>> AFAIU, for the kdump use-case mem=X@Y should suffice. >> >> We can modify some code to make mem=X@Y work well, >> but according to Documentation/admin-guide/kernel-parameters.txt, >> the common way is mem=X and memmap=X@Y, so mem=X@Y for mips seems >> odd, the intention of this patchset is to make mem= and memmap= >> work well and consistent with the other archs. > > These options are anyway not consistent on different architectures. > arm, mips and x86 implement mem= one way and arm64, powerpc and riscv in > another so there is no common way to use mem=. > > Your changes will break the existing systems that use mem= and memmap= > options because they change the semantics of their MIPS implementation. Thank you, I know your opinion. Let's wait for Thomas's review to get some more feedbacks. Thanks, Tiezhu > > For kexec/kdump use-cases modern architectures usually do not pass mem= but > rather prepare the memory map for the kexeced kernel to use. I believe this > would be the right solution. > >> Thanks, >> Tiezhu >> >>> >>>> Thanks, >>>> Tiezhu >>>> >>>>> >>>>>> v4: Fix some build warnings reported by kernel test robot >>>>>> >>>>>> v3: Modify patch #3 to maintain compatibility for memmap=limit{$,#,!}base, >>>>>> commented by Mike Rapoport, thank you >>>>>> >>>>>> v2: Add some new patches to support memmap=limit@base >>>>>> >>>>>> Tiezhu Yang (4): >>>>>> MIPS: Refactor early_parse_mem() to fix mem= parameter >>>>>> memblock: Introduce memblock_mem_range_remove_map() >>>>>> MIPS: Refactor early_parse_memmap() to fix memmap= parameter >>>>>> MIPS: Remove not used variable usermem >>>>>> >>>>>> arch/mips/kernel/setup.c | 69 ++++++++++++++++++++++-------------------------- >>>>>> include/linux/memblock.h | 1 + >>>>>> mm/memblock.c | 9 +++++-- >>>>>> 3 files changed, 40 insertions(+), 39 deletions(-) >>>>>> >>>>>> -- >>>>>> 2.1.0 >>>>>> >>>>> >>>> >>> >> > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter 2022-03-02 9:28 ` Tiezhu Yang @ 2022-03-02 12:50 ` Mike Rapoport 0 siblings, 0 replies; 26+ messages in thread From: Mike Rapoport @ 2022-03-02 12:50 UTC (permalink / raw) To: Tiezhu Yang Cc: Thomas Bogendoerfer, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On Wed, Mar 02, 2022 at 05:28:27PM +0800, Tiezhu Yang wrote: > > On 03/02/2022 04:03 PM, Mike Rapoport wrote: > > On Wed, Mar 02, 2022 at 09:50:49AM +0800, Tiezhu Yang wrote: > > [ 0.000000] Linux version 5.17.0-rc3+ (loongson@linux) (gcc (GCC) 7.3.1 > 20180303 (Red Hat 7.3.1-6), GNU ld version 2.28-13.fc21.loongson.6) #1 SMP > PREEMPT Wed Mar 2 09:07:39 CST 2022 > [ 0.000000] CpuClock = 1800000000 > [ 0.000000] The bridge chip is LS7A > [ 0.000000] CP0_Config3: CP0 16.3 (0xdc8030a0) > [ 0.000000] CP0_PageGrain: CP0 5.1 (0x28000000) > [ 0.000000] NUMA: Discovered 4 cpus on 1 nodes > [ 0.000000] Node0: mem_type:1, mem_start:0x200000, mem_size:0xee MB > [ 0.000000] start_pfn:0x80, end_pfn:0x3c00, num_physpages:0x3b80 > [ 0.000000] Node0: mem_type:2, mem_start:0x90200000, mem_size:0x6fe MB > [ 0.000000] start_pfn:0x24080, end_pfn:0x40000, > num_physpages:0x1fb00 > [ 0.000000] Node0: mem_type:2, mem_start:0x120000000, mem_size:0x1600 MB > [ 0.000000] start_pfn:0x48000, end_pfn:0xa0000, > num_physpages:0x77b00 > [ 0.000000] Node0's addrspace_offset is 0x0 > [ 0.000000] Node0: start_pfn=0x80, end_pfn=0xa0000 > [ 0.000000] NUMA: set cpumask cpu 0 on node 0 > [ 0.000000] NUMA: set cpumask cpu 1 on node 0 > [ 0.000000] NUMA: set cpumask cpu 2 on node 0 > [ 0.000000] NUMA: set cpumask cpu 3 on node 0 > [ 0.000000] printk: bootconsole [early0] enabled > [ 0.000000] CPU0 revision is: 0014c001 (ICT Loongson-3) > [ 0.000000] FPU revision is: 00f70501 > [ 0.000000] MSA revision is: 00060140 > [ 0.000000] OF: fdt: No chosen node found, continuing without > [ 0.000000] MIPS: machine is loongson,loongson64g-4core-ls7a > [ 0.000000] User-defined physical RAM map overwrite > [ 0.000000] Kernel sections are not in the memory maps > [ 0.000000] memblock_add: [0x0000000000200000-0x000000000231185f] > setup_arch+0x140/0x794 > [ 0.000000] memblock_reserve: [0x0000000001260520-0x0000000001262560] > setup_arch+0x148/0x794 > [ 0.000000] Initrd not found or empty - disabling initrd > [ 0.000000] memblock_alloc_try_nid: 8257 bytes align=0x40 nid=-1 > from=0x0000000000000000 max_addr=0x0000000000000000 > early_init_dt_alloc_memory_arch+0x30/0x60 > [ 0.000000] memblock_reserve: [0x0000000004000000-0x0000000004002040] > memblock_alloc_range_nid+0xf0/0x178 > [ 0.000000] memblock_alloc_try_nid: 37972 bytes align=0x8 nid=-1 > from=0x0000000000000000 max_addr=0x0000000000000000 > early_init_dt_alloc_memory_arch+0x30/0x60 > [ 0.000000] memblock_reserve: [0x0000000004002048-0x000000000400b49b] > memblock_alloc_range_nid+0xf0/0x178 As far as I can tell, the kernel lives in 0x200000 and using mem=3G@64M removes the memory with the kernel and also makes the kernel think there is memory between 0x400000 and 0xf000000 while there seem to be a hole up to 0x90200000. This definitely can be reason for the hangs. -- Sincerely yours, Mike. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter 2022-03-02 1:50 ` Tiezhu Yang 2022-03-02 8:03 ` Mike Rapoport @ 2022-03-04 17:05 ` Maciej W. Rozycki 2022-03-05 6:19 ` Tiezhu Yang 1 sibling, 1 reply; 26+ messages in thread From: Maciej W. Rozycki @ 2022-03-04 17:05 UTC (permalink / raw) To: Tiezhu Yang Cc: Mike Rapoport, Thomas Bogendoerfer, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On Wed, 2 Mar 2022, Tiezhu Yang wrote: > > As for memmap= option, it does not specify the memory map but rather alters > > the memory map passed by the firmware. Particularity in MIPS implementation > > it allows to add a single range of available or reserved memory. > > > > AFAIU, for the kdump use-case mem=X@Y should suffice. > > We can modify some code to make mem=X@Y work well, > but according to Documentation/admin-guide/kernel-parameters.txt, > the common way is mem=X and memmap=X@Y, so mem=X@Y for mips seems > odd, the intention of this patchset is to make mem= and memmap= > work well and consistent with the other archs. It is not the MIPS implementation that is odd, it is the others that have changed the semantics that are. When I added `mem=...' support to the MIPS platform, back on Dec 11th, 2000, which I needed for a system with with memory holes until I got proper memory probing implemented, AFAIR the only other implementation was for the x86 and naturally what I did for the MIPS platform was exactly the same. It used to be documented too, but the documentation was removed sometime back in 2003 when someone has changed the x86 semantics for reasons unknown to me and without letting people working on other platforms know, so things diverged. Please review: <https://lore.kernel.org/linux-mips/alpine.LFD.2.21.2010050133330.333514@eddie.linux-mips.org/> as it has been already discussed. If you have a system that hangs with `mem=3G' and which does have contiguous RAM available for the kernel to use from 0 through to 3GiB, then please either bisect the problem or try finding the root cause as it used to work at least those 21 years ago. Conversely if your system does *not* have such RAM available, then use the correct option(s) instead that reflect your memory map. It is preferable that the memory map be determined automatically either by the firmware and then passed to the kernel somehow, or a device tree entry, or probed by the kernel itself. You shouldn't have to specify `mem=...' by hand except for debugging or as a temporary workaround. For example I have an x86 system that Linux does not how to interrogate for RAM beyond 64MiB, so I do use `memmap=128M@0' (for legacy reasons the x86 platform has a special exception to always exclude area between 640K and 1M from being used even if not explicitly specified, but we do not have a need for such legacy such legacy concerns with the MIPS port). I consider it an interim measure however until the kernel has been fixed. Maciej ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter 2022-03-04 17:05 ` Maciej W. Rozycki @ 2022-03-05 6:19 ` Tiezhu Yang 2022-03-05 13:26 ` Mike Rapoport 0 siblings, 1 reply; 26+ messages in thread From: Tiezhu Yang @ 2022-03-05 6:19 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Mike Rapoport, Thomas Bogendoerfer, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On 03/05/2022 01:05 AM, Maciej W. Rozycki wrote: > On Wed, 2 Mar 2022, Tiezhu Yang wrote: > >>> As for memmap= option, it does not specify the memory map but rather alters >>> the memory map passed by the firmware. Particularity in MIPS implementation >>> it allows to add a single range of available or reserved memory. >>> >>> AFAIU, for the kdump use-case mem=X@Y should suffice. >> >> We can modify some code to make mem=X@Y work well, >> but according to Documentation/admin-guide/kernel-parameters.txt, >> the common way is mem=X and memmap=X@Y, so mem=X@Y for mips seems >> odd, the intention of this patchset is to make mem= and memmap= >> work well and consistent with the other archs. > > It is not the MIPS implementation that is odd, it is the others that have > changed the semantics that are. > > When I added `mem=...' support to the MIPS platform, back on Dec 11th, > 2000, which I needed for a system with with memory holes until I got > proper memory probing implemented, AFAIR the only other implementation was > for the x86 and naturally what I did for the MIPS platform was exactly the > same. It used to be documented too, but the documentation was removed > sometime back in 2003 when someone has changed the x86 semantics for > reasons unknown to me and without letting people working on other > platforms know, so things diverged. > > Please review: > > <https://lore.kernel.org/linux-mips/alpine.LFD.2.21.2010050133330.333514@eddie.linux-mips.org/> > > as it has been already discussed. > > If you have a system that hangs with `mem=3G' and which does have > contiguous RAM available for the kernel to use from 0 through to 3GiB, > then please either bisect the problem or try finding the root cause as it > used to work at least those 21 years ago. Conversely if your system does > *not* have such RAM available, then use the correct option(s) instead that > reflect your memory map. > > It is preferable that the memory map be determined automatically either > by the firmware and then passed to the kernel somehow, or a device tree > entry, or probed by the kernel itself. You shouldn't have to specify > `mem=...' by hand except for debugging or as a temporary workaround. > > For example I have an x86 system that Linux does not how to interrogate > for RAM beyond 64MiB, so I do use `memmap=128M@0' (for legacy reasons the > x86 platform has a special exception to always exclude area between 640K > and 1M from being used even if not explicitly specified, but we do not > have a need for such legacy such legacy concerns with the MIPS port). I > consider it an interim measure however until the kernel has been fixed. > > Maciej > Hi Mike, Thomas and Maciej, Thank you very much for your feedbacks and discussions. To be frank, I think mem= and memmap= are used for debugging and testing in most cases, the intention of this patchset is to refactor the related code to make them work well on mips. Now, if put the current patch #2 as the first patch, and then modify the current patch #1 to support both mem=limit and mem=limit@base (if @base is omitted, it is equivalent to mem=limit), the other patches #3 and #4 remain unchanged, make sense? I will send v5 for your review. Thanks, Tiezhu ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter 2022-03-05 6:19 ` Tiezhu Yang @ 2022-03-05 13:26 ` Mike Rapoport 2022-03-05 19:21 ` Maciej W. Rozycki 0 siblings, 1 reply; 26+ messages in thread From: Mike Rapoport @ 2022-03-05 13:26 UTC (permalink / raw) To: Tiezhu Yang Cc: Maciej W. Rozycki, Thomas Bogendoerfer, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On Sat, Mar 05, 2022 at 02:19:41PM +0800, Tiezhu Yang wrote: > > > On 03/05/2022 01:05 AM, Maciej W. Rozycki wrote: > > On Wed, 2 Mar 2022, Tiezhu Yang wrote: > > > > > > As for memmap= option, it does not specify the memory map but rather alters > > > > the memory map passed by the firmware. Particularity in MIPS implementation > > > > it allows to add a single range of available or reserved memory. > > > > > > > > AFAIU, for the kdump use-case mem=X@Y should suffice. > > > > > > We can modify some code to make mem=X@Y work well, > > > but according to Documentation/admin-guide/kernel-parameters.txt, > > > the common way is mem=X and memmap=X@Y, so mem=X@Y for mips seems > > > odd, the intention of this patchset is to make mem= and memmap= > > > work well and consistent with the other archs. > > > > It is not the MIPS implementation that is odd, it is the others that have > > changed the semantics that are. > > > > When I added `mem=...' support to the MIPS platform, back on Dec 11th, > > 2000, which I needed for a system with with memory holes until I got > > proper memory probing implemented, AFAIR the only other implementation was > > for the x86 and naturally what I did for the MIPS platform was exactly the > > same. It used to be documented too, but the documentation was removed > > sometime back in 2003 when someone has changed the x86 semantics for > > reasons unknown to me and without letting people working on other > > platforms know, so things diverged. > > > > Please review: > > > > <https://lore.kernel.org/linux-mips/alpine.LFD.2.21.2010050133330.333514@eddie.linux-mips.org/> > > > > as it has been already discussed. > > > > If you have a system that hangs with `mem=3G' and which does have > > contiguous RAM available for the kernel to use from 0 through to 3GiB, > > then please either bisect the problem or try finding the root cause as it > > used to work at least those 21 years ago. Conversely if your system does > > *not* have such RAM available, then use the correct option(s) instead that > > reflect your memory map. > > > > It is preferable that the memory map be determined automatically either > > by the firmware and then passed to the kernel somehow, or a device tree > > entry, or probed by the kernel itself. You shouldn't have to specify > > `mem=...' by hand except for debugging or as a temporary workaround. > > > > For example I have an x86 system that Linux does not how to interrogate > > for RAM beyond 64MiB, so I do use `memmap=128M@0' (for legacy reasons the > > x86 platform has a special exception to always exclude area between 640K > > and 1M from being used even if not explicitly specified, but we do not > > have a need for such legacy such legacy concerns with the MIPS port). I > > consider it an interim measure however until the kernel has been fixed. > > > > Maciej > > > > Hi Mike, Thomas and Maciej, > > Thank you very much for your feedbacks and discussions. > > To be frank, I think mem= and memmap= are used for debugging and testing > in most cases, the intention of this patchset is to refactor the related > code to make them work well on mips. mem= works fine on mips and there is no need to change it. If you must supply complex memory layout on the command line, consider implementing support for memmap=exact and multiple memmap= parameters on the kernel command line, like x86 does. > Now, if put the current patch #2 as the first patch, and then modify the > current patch #1 to support both mem=limit and mem=limit@base (if @base > is omitted, it is equivalent to mem=limit), the other patches #3 and #4 > remain unchanged, make sense? > > I will send v5 for your review. > > Thanks, > Tiezhu > -- Sincerely yours, Mike. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter 2022-03-05 13:26 ` Mike Rapoport @ 2022-03-05 19:21 ` Maciej W. Rozycki 2022-03-05 20:09 ` Mike Rapoport 2022-03-05 20:53 ` Maciej W. Rozycki 0 siblings, 2 replies; 26+ messages in thread From: Maciej W. Rozycki @ 2022-03-05 19:21 UTC (permalink / raw) To: Mike Rapoport Cc: Tiezhu Yang, Thomas Bogendoerfer, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On Sat, 5 Mar 2022, Mike Rapoport wrote: > > > For example I have an x86 system that Linux does not how to interrogate > > > for RAM beyond 64MiB, so I do use `memmap=128M@0' (for legacy reasons the > > > x86 platform has a special exception to always exclude area between 640K > > > and 1M from being used even if not explicitly specified, but we do not > > > have a need for such legacy such legacy concerns with the MIPS port). I > > > consider it an interim measure however until the kernel has been fixed. > > > > > > Maciej > > > > > > > Hi Mike, Thomas and Maciej, > > > > Thank you very much for your feedbacks and discussions. > > > > To be frank, I think mem= and memmap= are used for debugging and testing > > in most cases, the intention of this patchset is to refactor the related > > code to make them work well on mips. > > mem= works fine on mips and there is no need to change it. > > If you must supply complex memory layout on the command line, consider > implementing support for memmap=exact and multiple memmap= parameters on > the kernel command line, like x86 does. There's nothing to implement as the MIPS port has supported arbitrary memory maps since Dec 11th, 2000; that's almost 22 years now. C.f.: <https://lore.kernel.org/linux-mips/Pine.GSO.3.96.1000814133957.7256S-100000@delta.ds2.pg.gda.pl/>, <https://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git/commit/?id=97b7ae4257ef>. Sadly commit a09fc446fb6d ("[MIPS] setup.c: use early_param() for early command line parsing") removed last pieces of inline documentation; I don't know why things like that get approved, but neither I can take responsibility. Also to say (in said commit): "There's no point to rewrite some logic to parse command line to pass initrd parameters or to declare a user memory area. We could use instead parse_early_param() that does the same thing." is IMHO unfair given that the "rewrite" was there in place almost six years before `parse_early_param' even started to exist! Why do people assume things have always been like they see them at the time they look? Maciej ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter 2022-03-05 19:21 ` Maciej W. Rozycki @ 2022-03-05 20:09 ` Mike Rapoport 2022-03-06 1:22 ` Maciej W. Rozycki 2022-03-05 20:53 ` Maciej W. Rozycki 1 sibling, 1 reply; 26+ messages in thread From: Mike Rapoport @ 2022-03-05 20:09 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Tiezhu Yang, Thomas Bogendoerfer, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On Sat, Mar 05, 2022 at 07:21:15PM +0000, Maciej W. Rozycki wrote: > On Sat, 5 Mar 2022, Mike Rapoport wrote: > > > > > For example I have an x86 system that Linux does not how to interrogate > > > > for RAM beyond 64MiB, so I do use `memmap=128M@0' (for legacy reasons the > > > > x86 platform has a special exception to always exclude area between 640K > > > > and 1M from being used even if not explicitly specified, but we do not > > > > have a need for such legacy such legacy concerns with the MIPS port). I > > > > consider it an interim measure however until the kernel has been fixed. > > > > > > > > Maciej > > > > > > > > > > Hi Mike, Thomas and Maciej, > > > > > > Thank you very much for your feedbacks and discussions. > > > > > > To be frank, I think mem= and memmap= are used for debugging and testing > > > in most cases, the intention of this patchset is to refactor the related > > > code to make them work well on mips. > > > > mem= works fine on mips and there is no need to change it. > > > > If you must supply complex memory layout on the command line, consider > > implementing support for memmap=exact and multiple memmap= parameters on > > the kernel command line, like x86 does. > > There's nothing to implement as the MIPS port has supported arbitrary > memory maps since Dec 11th, 2000; that's almost 22 years now. C.f.: > <https://lore.kernel.org/linux-mips/Pine.GSO.3.96.1000814133957.7256S-100000@delta.ds2.pg.gda.pl/>, > <https://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git/commit/?id=97b7ae4257ef>. You are right, and providing mem=X@Y for each contiguous memory range should work even after 22 years. I missed the fact that mem= can be repeated several times. > Sadly commit a09fc446fb6d ("[MIPS] setup.c: use early_param() for early > command line parsing") removed last pieces of inline documentation; I > don't know why things like that get approved, but neither I can take > responsibility. This is sad indeed, but we still can update the kernel-parameters.txt with a MIPS paragraph. > Maciej -- Sincerely yours, Mike. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter 2022-03-05 20:09 ` Mike Rapoport @ 2022-03-06 1:22 ` Maciej W. Rozycki 0 siblings, 0 replies; 26+ messages in thread From: Maciej W. Rozycki @ 2022-03-06 1:22 UTC (permalink / raw) To: Mike Rapoport Cc: Tiezhu Yang, Thomas Bogendoerfer, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On Sat, 5 Mar 2022, Mike Rapoport wrote: > > There's nothing to implement as the MIPS port has supported arbitrary > > memory maps since Dec 11th, 2000; that's almost 22 years now. C.f.: > > <https://lore.kernel.org/linux-mips/Pine.GSO.3.96.1000814133957.7256S-100000@delta.ds2.pg.gda.pl/>, > > <https://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git/commit/?id=97b7ae4257ef>. > > You are right, and providing mem=X@Y for each contiguous memory range > should work even after 22 years. > I missed the fact that mem= can be repeated several times. Yep, I have now finally tracked down the original bootstrap log for the first try of that change: This DECstation is a DS5000/2x0 Loading R[23]00 MMU routines. CPU revision is: 00000230 Primary instruction cache 64kb, linesize 4 bytes Primary data cache 64kb, linesize 4 bytes Linux version 2.4.0-test5 (macro@macro.ds2.pg.gda.pl) (gcc version 2.95.3 19991030 (prerelease)) #16 Sun Aug 13 16:43:22 CEST 2000 PROM-provided physical RAM map: memory: 06800000 @ 00000000 memory: 00800000 @ 08000000 memory: 00800000 @ 0a000000 User-defined physical RAM map: memory: 06800000 @ 00000000 memory: 00800000 @ 08000000 memory: 00800000 @ 0a000000 memory: 00800000 @ 0c000000 On node 0 totalpages: 51200 zone(0): 51200 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: rw console=ttyS2 mem=104M@0M mem=8M@128M mem=8M@160M mem=8M@192M Calibrating delay loop... 39.85 BogoMIPS Memory: 127852k/204800k available (2403k kernel code, 76948k reserved, 610k data, 72k init) [...] NB that system is still in service, with more RAM since added. > > Sadly commit a09fc446fb6d ("[MIPS] setup.c: use early_param() for early > > command line parsing") removed last pieces of inline documentation; I > > don't know why things like that get approved, but neither I can take > > responsibility. > > This is sad indeed, but we still can update the kernel-parameters.txt with > a MIPS paragraph. Sure, patches are welcome. Maciej ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter 2022-03-05 19:21 ` Maciej W. Rozycki 2022-03-05 20:09 ` Mike Rapoport @ 2022-03-05 20:53 ` Maciej W. Rozycki 1 sibling, 0 replies; 26+ messages in thread From: Maciej W. Rozycki @ 2022-03-05 20:53 UTC (permalink / raw) To: Mike Rapoport Cc: Tiezhu Yang, Thomas Bogendoerfer, Andrew Morton, Xuefeng Li, linux-mips, linux-mm, linux-kernel On Sat, 5 Mar 2022, Maciej W. Rozycki wrote: > Also to say (in said commit): > > "There's no point to rewrite some logic to parse command line > to pass initrd parameters or to declare a user memory area. > We could use instead parse_early_param() that does the same > thing." > > is IMHO unfair given that the "rewrite" was there in place almost six > years before `parse_early_param' even started to exist! Why do people > assume things have always been like they see them at the time they look? Self-correction for an incorrect last-moment edit: four years before rather than six (`parse_early_param' went in upstream shortly before: <https://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git/commit/?id=5145764263ab>). Maciej ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2022-03-07 23:09 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-03-01 4:28 [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter Tiezhu Yang 2022-03-01 4:28 ` [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter Tiezhu Yang 2022-03-04 15:10 ` Thomas Bogendoerfer 2022-03-04 15:35 ` Thomas Bogendoerfer 2022-03-04 17:11 ` Maciej W. Rozycki 2022-03-05 13:13 ` Mike Rapoport 2022-03-07 16:29 ` Thomas Bogendoerfer 2022-03-07 22:07 ` Mike Rapoport 2022-03-07 23:09 ` Maciej W. Rozycki 2022-03-01 4:28 ` [PATCH v4 2/4] memblock: Introduce memblock_mem_range_remove_map() Tiezhu Yang 2022-03-01 4:29 ` [PATCH v4 3/4] MIPS: Refactor early_parse_memmap() to fix memmap= parameter Tiezhu Yang 2022-03-01 4:29 ` [PATCH v4 4/4] MIPS: Remove not used variable usermem Tiezhu Yang 2022-03-01 9:55 ` [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter Mike Rapoport 2022-03-01 11:51 ` Tiezhu Yang 2022-03-01 14:31 ` Mike Rapoport 2022-03-02 1:50 ` Tiezhu Yang 2022-03-02 8:03 ` Mike Rapoport 2022-03-02 9:28 ` Tiezhu Yang 2022-03-02 12:50 ` Mike Rapoport 2022-03-04 17:05 ` Maciej W. Rozycki 2022-03-05 6:19 ` Tiezhu Yang 2022-03-05 13:26 ` Mike Rapoport 2022-03-05 19:21 ` Maciej W. Rozycki 2022-03-05 20:09 ` Mike Rapoport 2022-03-06 1:22 ` Maciej W. Rozycki 2022-03-05 20:53 ` Maciej W. Rozycki
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).