ubldr: Bump heap size from 512K to 8MB

[kevans]

Summary

lualoader in itself only uses another ~200K, but there seems to be no reason not to bump it a little higher to give us some more wiggle room.

With this, I can boot using a menu-enabled lualoader, no problem and reasonably fast.

[kevans]

This combined with D14472 yields a working lualoader on armv7 that isn't painfully slow.

[imp]

I think this is fine, but what does it do to the minimum sized we can boot on? And does this interfere with where we load the kernel? Is there an overlap? Of is that just a u-boot issue?

[• ian]

ubldr will find an unused block of space large enough to load the kernel into, and is smart enough to avoid loading it over top of itself or its own heap. There's nothing that prevents running into the stack (which is uboot's stack, at the very top of physical ram), but generally $loadaddr in uboot is somewhere near the bottom of ram and the vast majority of the memory on the board is available between the ubldr heap and stack.

Whether 8mb is a good number depends on whether ubldr is used on any small-memory systems. When I said "even 8mb would work fine" in irc the other day, I was thinking in terms of doing a smoke-test to see if increasing the heap fixed the problem. It might be interesting to see how much ubldr is really using, which can probably be done by defining ZALLOCDEBUG and calling zallocstats() just before launching the kernel. Maybe 2mb is more than enough.

[imp]

In D14471#303486, @ian wrote:

ubldr will find an unused block of space large enough to load the kernel into, and is smart enough to avoid loading it over top of itself or its own heap. There's nothing that prevents running into the stack (which is uboot's stack, at the very top of physical ram), but generally $loadaddr in uboot is somewhere near the bottom of ram and the vast majority of the memory on the board is available between the ubldr heap and stack.

Whether 8mb is a good number depends on whether ubldr is used on any small-memory systems. When I said "even 8mb would work fine" in irc the other day, I was thinking in terms of doing a smoke-test to see if increasing the heap fixed the problem. It might be interesting to see how much ubldr is really using, which can probably be done by defining ZALLOCDEBUG and calling zallocstats() just before launching the kernel. Maybe 2mb is more than enough.

Yea, I have no horse in this race. We had an issue with block cache that worked great on large systems, but made it impossible to boot on even 128MB machines, for example, which at the time were still viewed as not crazy small. I'm asking the question to make sure we don't wind up in the same place again without knowing.

On x86, I also think we have issues where we load the kernel at 2MB always, and so we can't have more than 1MB of heap... Or did before that got fixed. I also want to make sure that we're not setting ourselves up for some kind of silent overlap. If none of these are a concern, then great.

[kevans]

Heh, talk about misinterpretation. =) My apologies, @ian

For lualoader purposes, I think we could happily live with a bump to 1MB. A "fully loaded" (menus, everything enabled) lualoader requires ~210KB maximum in absolute worst-case scenarios. A trimmed lualoader (without the menus) takes up about ~100KB. I don't immediately recall if this usage is purely heap consumption or a mixture, or what that distribution might look like.

So even in the worst case scenario, adding an extra 512KB is almost twice as much as we actually need (assuming 100% of the 210KB figure is in the heap).

[• ian]

I just re-discovered that ubldr already has a command that displays heap usage, cleverly named "heap". On a forth-based armv7 after having loaded config and the kernel (no modules) it shows this (ubldr was loaded at 0x12000000)...

heap base at 0x1203d5b0, top at 0x1208e000, used 330320

Might be interesting to see how the lua number compares, but I'm okay with this change in general, whatever the final size bump ends up being (now that it's not the really-big number I suggested for debugging purposes).

[kevans]

Some more datapoints, using the re-discovered heap command:

lualoader, no menus, kernel loaded:
heap base at 0x42050028, top at 0x420ab000, used 372696

lualoader, menus, kernel loaded:
heap base at 0x42050028, top at 0x420d5000, used 544728

So it seems that we're good in the general case without menus and a bump to 1MB would be more than sufficient for lualoader with menus. I don't see our lua stuff growing much bulkier than it is now; if we can afford it then I think 1MB would be a good choice.