diff mbox series

RISC-V: enable sparsemem by default for defconfig

Message ID 20221021160028.4042304-1-conor@kernel.org (mailing list archive)
State Accepted
Commit 41555cc9e2e9778ddc7c0293a4a2e4995e332643
Delegated to: Palmer Dabbelt
Headers show
Series RISC-V: enable sparsemem by default for defconfig | expand

Commit Message

Conor Dooley Oct. 21, 2022, 4 p.m. UTC
From: Conor Dooley <conor.dooley@microchip.com>

on an arch level, RISC-V defaults to FLATMEM. On PolarFire SoC, the
memory layout is almost always sparse, with a maximum of 1 GiB at
0x8000_0000 & a possible 16 GiB range at 0x10_0000_0000. The Icicle kit,
for example, has 2 GiB of DDR - so there's a big hole in the memory map
between the two gigs. Prior to v6.1-rc1, boot times from defconfig
builds were pretty bad on Icicle but enabling sparsemem would fix those
issues. As of v6.1-rc1, the Icicle kit no longer boots from defconfig
builds with the in-kernel devicetree. A change to the memory map
resulted in a futher "sparse-ification", producing a splat on boot:

	OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
	Machine model: Microchip PolarFire-SoC Icicle Kit
	earlycon: ns16550a0 at MMIO32 0x0000000020100000 (options '115200n8')
	printk: bootconsole [ns16550a0] enabled
	printk: debug: skip boot console de-registration.
	efi: UEFI not found.
	Zone ranges:
	  DMA32    [mem 0x0000000080200000-0x00000000ffffffff]
	  Normal   [mem 0x0000000100000000-0x000000107fffffff]
	Movable zone start for each node
	Early memory node ranges
	  node   0: [mem 0x0000000080200000-0x00000000bfbfffff]
	  node   0: [mem 0x00000000bfc00000-0x00000000bfffffff]
	  node   0: [mem 0x0000001040000000-0x000000107fffffff]
	Initmem setup node 0 [mem 0x0000000080200000-0x000000107fffffff]
	Kernel panic - not syncing: Failed to allocate 1073741824 bytes for node 0 memory map
	CPU: 0 PID: 0 Comm: swapper Not tainted 5.19.0-dirty #1
	Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)
	Call Trace:
	[<ffffffff800057f0>] show_stack+0x30/0x3c
	[<ffffffff807d5802>] dump_stack_lvl+0x4a/0x66
	[<ffffffff807d5836>] dump_stack+0x18/0x20
	[<ffffffff807d1ae8>] panic+0x124/0x2c6
	[<ffffffff80814064>] free_area_init_core+0x0/0x11e
	[<ffffffff80813720>] free_area_init_node+0xc2/0xf6
	[<ffffffff8081331e>] free_area_init+0x222/0x260
	[<ffffffff808064d6>] misc_mem_init+0x62/0x9a
	[<ffffffff80803cb2>] setup_arch+0xb0/0xea
	[<ffffffff8080039a>] start_kernel+0x88/0x4ee
	---[ end Kernel panic - not syncing: Failed to allocate 1073741824 bytes for node 0 memory map ]---

With the aim of keeping defconfig builds booting on icicle, enable
SPARSEMEM_MANUAL.

Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---

I had it in my head that keeping defconfig booting on ~all~ as many
platforms as possible was a goal, I think from one of the Kconfig.socs
conversations. Hence this patch..

 arch/riscv/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

Comments

Palmer Dabbelt Nov. 29, 2022, 9:21 p.m. UTC | #1
On Fri, 21 Oct 2022 17:00:30 +0100, Conor Dooley wrote:
> From: Conor Dooley <conor.dooley@microchip.com>
> 
> on an arch level, RISC-V defaults to FLATMEM. On PolarFire SoC, the
> memory layout is almost always sparse, with a maximum of 1 GiB at
> 0x8000_0000 & a possible 16 GiB range at 0x10_0000_0000. The Icicle kit,
> for example, has 2 GiB of DDR - so there's a big hole in the memory map
> between the two gigs. Prior to v6.1-rc1, boot times from defconfig
> builds were pretty bad on Icicle but enabling sparsemem would fix those
> issues. As of v6.1-rc1, the Icicle kit no longer boots from defconfig
> builds with the in-kernel devicetree. A change to the memory map
> resulted in a futher "sparse-ification", producing a splat on boot:
> 
> [...]

Applied, thanks!

[1/1] RISC-V: enable sparsemem by default for defconfig
      https://git.kernel.org/palmer/c/41555cc9e2e9

I put this one on for-next under the argument it's not actually fixing a
regression: if flatmem is now broken then that's a regression, but just turning
it off isn't really the fix (even if it's still a reasonable thing to do).

Maybe that's kind of pedantic, but it's late in the cycle.

Best regards,
patchwork-bot+linux-riscv@kernel.org Nov. 29, 2022, 9:30 p.m. UTC | #2
Hello:

This patch was applied to riscv/linux.git (for-next)
by Palmer Dabbelt <palmer@rivosinc.com>:

On Fri, 21 Oct 2022 17:00:30 +0100 you wrote:
> From: Conor Dooley <conor.dooley@microchip.com>
> 
> on an arch level, RISC-V defaults to FLATMEM. On PolarFire SoC, the
> memory layout is almost always sparse, with a maximum of 1 GiB at
> 0x8000_0000 & a possible 16 GiB range at 0x10_0000_0000. The Icicle kit,
> for example, has 2 GiB of DDR - so there's a big hole in the memory map
> between the two gigs. Prior to v6.1-rc1, boot times from defconfig
> builds were pretty bad on Icicle but enabling sparsemem would fix those
> issues. As of v6.1-rc1, the Icicle kit no longer boots from defconfig
> builds with the in-kernel devicetree. A change to the memory map
> resulted in a futher "sparse-ification", producing a splat on boot:
> 
> [...]

Here is the summary with links:
  - RISC-V: enable sparsemem by default for defconfig
    https://git.kernel.org/riscv/c/41555cc9e2e9

You are awesome, thank you!
Conor Dooley Nov. 29, 2022, 9:36 p.m. UTC | #3
On Tue, Nov 29, 2022 at 01:21:11PM -0800, Palmer Dabbelt wrote:
> On Fri, 21 Oct 2022 17:00:30 +0100, Conor Dooley wrote:
> > From: Conor Dooley <conor.dooley@microchip.com>
> > 
> > on an arch level, RISC-V defaults to FLATMEM. On PolarFire SoC, the
> > memory layout is almost always sparse, with a maximum of 1 GiB at
> > 0x8000_0000 & a possible 16 GiB range at 0x10_0000_0000. The Icicle kit,
> > for example, has 2 GiB of DDR - so there's a big hole in the memory map
> > between the two gigs. Prior to v6.1-rc1, boot times from defconfig
> > builds were pretty bad on Icicle but enabling sparsemem would fix those
> > issues. As of v6.1-rc1, the Icicle kit no longer boots from defconfig
> > builds with the in-kernel devicetree. A change to the memory map
> > resulted in a futher "sparse-ification", producing a splat on boot:
> > 
> > [...]
> 
> Applied, thanks!
> 
> [1/1] RISC-V: enable sparsemem by default for defconfig
>       https://git.kernel.org/palmer/c/41555cc9e2e9
> 
> I put this one on for-next under the argument it's not actually fixing a
> regression: if flatmem is now broken then that's a regression, but just turning
> it off isn't really the fix (even if it's still a reasonable thing to do).

flatmem is not broken, or at least - I haven't seen any evidence of it.
It's just that to support multiplatform stuff properly we should not be
assuming flatmem since systems may not fit the bill. The above oops is
because the memory map is too sparse for flatmem to keep papering over
the cracks any more after some DT changes I made for v6.1

> Maybe that's kind of pedantic, but it's late in the cycle.

No, that's perfectly reasonable to me. I'll just add an exception in our
CI for testing v6.1 when it becomes a stable kernel to not build
defconfig as-is ;)

Thanks,
Conor.
Palmer Dabbelt Nov. 29, 2022, 9:48 p.m. UTC | #4
On Tue, 29 Nov 2022 13:36:01 PST (-0800), Conor Dooley wrote:
> On Tue, Nov 29, 2022 at 01:21:11PM -0800, Palmer Dabbelt wrote:
>> On Fri, 21 Oct 2022 17:00:30 +0100, Conor Dooley wrote:
>> > From: Conor Dooley <conor.dooley@microchip.com>
>> >
>> > on an arch level, RISC-V defaults to FLATMEM. On PolarFire SoC, the
>> > memory layout is almost always sparse, with a maximum of 1 GiB at
>> > 0x8000_0000 & a possible 16 GiB range at 0x10_0000_0000. The Icicle kit,
>> > for example, has 2 GiB of DDR - so there's a big hole in the memory map
>> > between the two gigs. Prior to v6.1-rc1, boot times from defconfig
>> > builds were pretty bad on Icicle but enabling sparsemem would fix those
>> > issues. As of v6.1-rc1, the Icicle kit no longer boots from defconfig
>> > builds with the in-kernel devicetree. A change to the memory map
>> > resulted in a futher "sparse-ification", producing a splat on boot:
>> >
>> > [...]
>>
>> Applied, thanks!
>>
>> [1/1] RISC-V: enable sparsemem by default for defconfig
>>       https://git.kernel.org/palmer/c/41555cc9e2e9
>>
>> I put this one on for-next under the argument it's not actually fixing a
>> regression: if flatmem is now broken then that's a regression, but just turning
>> it off isn't really the fix (even if it's still a reasonable thing to do).
>
> flatmem is not broken, or at least - I haven't seen any evidence of it.
> It's just that to support multiplatform stuff properly we should not be
> assuming flatmem since systems may not fit the bill. The above oops is
> because the memory map is too sparse for flatmem to keep papering over
> the cracks any more after some DT changes I made for v6.1
>
>> Maybe that's kind of pedantic, but it's late in the cycle.
>
> No, that's perfectly reasonable to me. I'll just add an exception in our
> CI for testing v6.1 when it becomes a stable kernel to not build
> defconfig as-is ;)

OK, sounds good.

>
> Thanks,
> Conor.
diff mbox series

Patch

diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index 05fd5fcf24f9..daba5d743862 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -38,6 +38,7 @@  CONFIG_KVM=m
 CONFIG_JUMP_LABEL=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
+CONFIG_SPARSEMEM_MANUAL=y
 CONFIG_BLK_DEV_THROTTLING=y
 CONFIG_NET=y
 CONFIG_PACKET=y