From: Conor Dooley <conor@kernel.org>
To: Palmer Dabbelt <palmer@rivosinc.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
linux-riscv@lists.infradead.org, daire.mcnamara@microchip.com,
Conor Dooley <conor.dooley@microchip.com>
Subject: Re: [PATCH] RISC-V: enable sparsemem by default for defconfig
Date: Tue, 29 Nov 2022 21:36:01 +0000 [thread overview]
Message-ID: <Y4Z7Qcfglxv6EuZz@spud> (raw)
In-Reply-To: <166975687110.10326.1643787645847753206.b4-ty@rivosinc.com>
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.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2022-11-29 21:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-21 16:00 [PATCH] RISC-V: enable sparsemem by default for defconfig Conor Dooley
2022-11-29 21:21 ` Palmer Dabbelt
2022-11-29 21:36 ` Conor Dooley [this message]
2022-11-29 21:48 ` Palmer Dabbelt
2022-11-29 21:30 ` patchwork-bot+linux-riscv
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y4Z7Qcfglxv6EuZz@spud \
--to=conor@kernel.org \
--cc=conor.dooley@microchip.com \
--cc=daire.mcnamara@microchip.com \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=palmer@rivosinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox