On 10.10.2009 23:55, Myles Watson wrote:
Myles Watson schrieb:
Fix AP_CODE_IN_CAR (only selected for two boards), STACK_SIZE, and
HEAP_SIZE.
One thing though: We're using lzma per default now if we're using compression. This means each board needs at _least_ a stack size of 0x8000.
Why does LZMA use so much memory from the stack? Couldn't we convert it to use heap so that it is easier to tell when you run out? I guess that would make it dependent on a malloc call?
Yes, the malloc dependency is what originally caused me to use the stack instead.
Those boards with STACK_SIZE being 0x2000 or 0x8000 are definitely broken (and if they boot, they do by accident)
So since it's broken with Kconfig and newconfig, how can we decide what the correct stack size should be?
What's the downside of a large stack?
If you make the stack too large and you have multiple cores in CAR at the same time, the CAR size is too small for all stacks.
What breakage should occur, heap corruption? Should we check before LZMA how much stack is left?
The best choice would be to make sure no AP ever uses LZMA. Let me explain. If one AP uses LZMA, it's very likely due to decompressing some CBFS member. If one AP does that, it is very likely all of them are doing it, probably even at the same time (at least we had that problem in the past). LZMA decompression uses the destination buffer as scratch pad which means if you are decompressing the same file to the same destination on different cores, you are likely to get garbage there in the meantime or even at the end. Plus, decompressing one file once per AP is totally wasteful. Nobody wants that. Two ways to solve this: 1. Have the first AP decompress the CBFS member it wants to run and block all other APs until decompression is complete (but you still need a big stack for that first AP). 2. Have the BSP decompress the CBFS member the APs want to run, then start the APs. Big benefit here is you can avoid locking and the stack of APs can stay small.
Regards, Carl-Daniel