On Mon, Sep 25, 2023 at 05:27:26PM +0200, Mark Kettenis wrote: > > Date: Mon, 25 Sep 2023 11:21:26 -0400 > > From: Tom Rini <tr...@konsulko.com> > > > > On Sun, Sep 24, 2023 at 04:48:32PM +0530, Udit Kumar wrote: > > > > > In case of new memory range to be added is coalesced > > > with any already added non last lmb region. > > > > > > And there is possibility that, then region in which new memory > > > range added is not adjacent to next region. But have some > > > sections are overlapping. > > > > > > So along with adjacency check with next lmb region, > > > check for overlap should be done. > > > > > > In case overlap is found, adjust and merge these two lmb > > > region into one. > > > > > > Reported-by: Suman Anna <s-a...@ti.com> > > > Signed-off-by: Udit Kumar <u-kum...@ti.com> > > > > This is good! I wonder if this addresses the issue that has caused > > other platforms to need to set CONFIG_LMB_MAX_REGIONS=64 and I'm > > wondering if any of the other maintainers I've cc'd here can drop back > > to the default number of regions and then re-test their failure case? > > Thanks! > > Hi Tom, > > For the Apple M1 systems I don't think it makes sense to reduce the > number of regions. These systems don't have TPL or SPL, have plenty > of memory (at least 8GB) and are really fast. And we anticipate that > the number of memory regions will only grow in the future.
This partly gets at what I see as part of the problem. It's been unclear to me if it's reasonable to just bump the default to 64 for aarch64 (and riscv?) because the problem is that 16 is truly too small, or given what we're doing we still don't need a ton of LMB regions as at the end of the day things should be coalesced in to just a few and it's been an underlying bug in an area everyone assumed wasn't buggy. -- Tom
signature.asc
Description: PGP signature
