Hi Michael,
On Mon, Mar 22, 2021 at 10:48 PM Michael Schmitz <schmitz...@gmail.com> wrote:
> Based on the commit that Geert cited, I'd be inclined to sort chunks by
> physical address, find the lowest chunk having size >= 16 MB and put that
> one and the higher ones into bootinfo. (Or failing that, find the one
> having size >= 8 MB, or failing that, 4 MB.)
>
> Do you know the size of the uncompressed kernel at that stage? That way, you
> could skip all RAM banks smaller than that size (plus some margin for the
> initial mappings, one 4k page for each 4 MB of chunk size plus required
> number of pointer table pages) and use the first one (lowest address one)
> that satisfies such a minimum size criterion.
>
> In this way, you won't lose all of the smaller but still useful banks, just
> in case a user arranged the banks in ascending size order.
>
> (Skipping the lower address banks isn't strictly required BTW - the kernel
> will warn and ignore them as it used to. No harm done.)
>
> A full sort isn't really needed here but does offer some determinism. Are
> there implications for mm data structures? E.g. memblock_add_node() is
> called for each chunk, and if the chunks are in the "wrong" order, perhaps
> that would affect mm algorithms (?)
>
> There is no checks about order that I would have seen. But the reason why
> memory with lower addresses than mapped by head.S can't be used still isn't
> clear to me. Best leave the rest of the chunk list in address order.
Because the logic handling physical pages is basically a data structure
like (simplied) pages[address - base], with base the address of the first
chunk. So you can't have a negative index.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
