[PATCH] RISC-V: enable sparsemem by default for defconfig

Palmer Dabbelt palmer at rivosinc.com
Tue Nov 29 13:48:26 PST 2022


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



More information about the linux-riscv mailing list