public inbox for linux-riscv@lists.infradead.org
 help / color / mirror / Atom feed
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

  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