Re: Kernel uses only half of Mac IIci memory with built-in video
Hi Michael,
On Mon, Mar 22, 2021 at 10:48 PM Michael Schmitz <schmitzmic@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 -- geert@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
Reply to: