Hi Mark/Tom
On 9/25/2023 9:01 PM, Tom Rini wrote:
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.
Did we observed overlapped memory regions added in lmb region ?
which leads to increase in default number of regions.
