Message ID | 20181219161616.10422-1-Eugeniy.Paltsev@synopsys.com |
---|---|
State | New |
Headers | show |
Series | ARC: adjust memblock_reserve of kernel memory | expand |
Hi, [This is an automated email] This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all The bot has tested the following trees: v4.19.10, v4.14.89, v4.9.146, v4.4.168, v3.18.130, v4.19.10: Build OK! v4.14.89: Build OK! v4.9.146: Build OK! v4.4.168: Failed to apply! Possible dependencies: 26f9d5fd82ca ("ARC: support HIGHMEM even without PAE40") 37eda9df5bd8 ("ARC: mm: Introduce explicit super page size support") c2ff5cf2735c ("ARC: mm: Use virt_to_pfn() for addr >> PAGE_SHIFT pattern") v3.18.130: Failed to apply! Possible dependencies: 09f3b37e4e3b ("ARC: entry.S: Introduce INTERRUPT_{PROLOGUE,EPILOGUE}") 1f6ccfff6314 ("ARCv2: Support for ARCv2 ISA and HS38x cores") 26f9d5fd82ca ("ARC: support HIGHMEM even without PAE40") 37eda9df5bd8 ("ARC: mm: Introduce explicit super page size support") 4bf4564b27db ("ARC: entry.S: comments cleanup") 565a9b497c51 ("ARC: RIP broken 64bit RTSC") 5793e273a134 ("ARC: intc: split into ARCompact ISA specific, common bits") 6d1a20b1d237 ("ARC: entry.S: split into ARCompact ISA specific, common bits") 820970a5aa3c ("ARCv2: [intc] HS38 core interrupt controller") 9b8c7d1e7107 ("ARC: entry.S: FAKE_RET_FROM_EXCPN can always use r9") a44ec8bd2a55 ("ARC: Fix RTT boot printing") a615b47dbf0d ("ARC: entry.S: confine EXCEPTION_* macros to one file") a8717d280879 ("ARC: entry.S: Trap handler to use r10 for syscall vs. brkpt decision") c10d6969b095 ("ARC: entry.S: Ensure that restore_regs is local to compilation unit") dc9e234f91c7 ("ARC: cosmetic: Remove unused ECR bitfield masks") f033737e77d9 ("ARC: entry.S: canonical'ize EXCEPTION_{PROLOGUE,EPILOGUE}") fbfa26ae3b20 ("ARC: entry.S: common'ize scrtach reg freeup in intr + exceptions") How should we proceed with this patch? -- Thanks, Sasha
On 12/19/18 8:16 AM, Eugeniy Paltsev wrote: > In setup_arch_memory we reserve the memory area wherein the kernel > is located. Current implementation may reserve more memory than > it actually required in case of CONFIG_LINUX_LINK_BASE is not > equal to CONFIG_LINUX_RAM_BASE. This happens because we calculate > start of the reserved region relatively to the CONFIG_LINUX_RAM_BASE > and end of the region relatively to the CONFIG_LINUX_RAM_BASE. > > For example in case of HSDK board we wasted 256MiB of physical memory: > ------------------->8------------------------------ > Memory: 770416K/1048576K available (5496K kernel code, > 240K rwdata, 1064K rodata, 2200K init, 275K bss, > 278160K reserved, 0K cma-reserved) > ------------------->8------------------------------ > > Fix that. > > Cc: stable@vger.kernel.org > Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> LGTM. I presume you have booted HSDK with it and done some smoke testing. -Vineet
On 12/19/18 8:16 AM, Eugeniy Paltsev wrote: > In setup_arch_memory we reserve the memory area wherein the kernel > is located. Current implementation may reserve more memory than > it actually required in case of CONFIG_LINUX_LINK_BASE is not > equal to CONFIG_LINUX_RAM_BASE. This happens because we calculate > start of the reserved region relatively to the CONFIG_LINUX_RAM_BASE > and end of the region relatively to the CONFIG_LINUX_RAM_BASE. > > For example in case of HSDK board we wasted 256MiB of physical memory: > ------------------->8------------------------------ > Memory: 770416K/1048576K available (5496K kernel code, > 240K rwdata, 1064K rodata, 2200K init, 275K bss, > 278160K reserved, 0K cma-reserved) > ------------------->8------------------------------ > > Fix that. > > Cc: stable@vger.kernel.org For backports, please also check how far back this needs to be applied (else we get bot emails specifying they don't apply to ver x, y z) > Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> > --- > arch/arc/mm/init.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c > index f8fe5668b30f..a56e6a8ed259 100644 > --- a/arch/arc/mm/init.c > +++ b/arch/arc/mm/init.c > @@ -137,7 +137,8 @@ void __init setup_arch_memory(void) > */ > > memblock_add_node(low_mem_start, low_mem_sz, 0); > - memblock_reserve(low_mem_start, __pa(_end) - low_mem_start); > + memblock_reserve(CONFIG_LINUX_LINK_BASE, > + __pa(_end) - CONFIG_LINUX_LINK_BASE); > > #ifdef CONFIG_BLK_DEV_INITRD > if (initrd_start) So I looked into the history for restricting stable, and it seems this was introduced with our earlier work for HSDK. Before commit 9ed68785f7f this code was ok, since low_mem_start = CONFIG_LINUX_LINK_BASE. With the patch we changed low_mem_start to CONFIG_LINUX_RAM_BASE and missed this. -Vineet
diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c index f8fe5668b30f..a56e6a8ed259 100644 --- a/arch/arc/mm/init.c +++ b/arch/arc/mm/init.c @@ -137,7 +137,8 @@ void __init setup_arch_memory(void) */ memblock_add_node(low_mem_start, low_mem_sz, 0); - memblock_reserve(low_mem_start, __pa(_end) - low_mem_start); + memblock_reserve(CONFIG_LINUX_LINK_BASE, + __pa(_end) - CONFIG_LINUX_LINK_BASE); #ifdef CONFIG_BLK_DEV_INITRD if (initrd_start)
In setup_arch_memory we reserve the memory area wherein the kernel is located. Current implementation may reserve more memory than it actually required in case of CONFIG_LINUX_LINK_BASE is not equal to CONFIG_LINUX_RAM_BASE. This happens because we calculate start of the reserved region relatively to the CONFIG_LINUX_RAM_BASE and end of the region relatively to the CONFIG_LINUX_RAM_BASE. For example in case of HSDK board we wasted 256MiB of physical memory: ------------------->8------------------------------ Memory: 770416K/1048576K available (5496K kernel code, 240K rwdata, 1064K rodata, 2200K init, 275K bss, 278160K reserved, 0K cma-reserved) ------------------->8------------------------------ Fix that. Cc: stable@vger.kernel.org Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> --- arch/arc/mm/init.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)