[U-Boot] [U-BOOT] [PATCH] env: reduce the stack footprint for the env buf

[Lei Wen]

Hi Wolfgang,

On Mon, Feb 7, 2011 at 12:08 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Lei Wen,
>
> In message <AANLkTin1U7WZnVKhOaTzkW4UEDQ1iZtLZBo6-qBMoUzY at mail.gmail.com> you wrote:
>>
>> > malloc arena and stack are adjacent.  If you have enough free room in
>> > the malloc arena for the environment buffers, but cannot afford to
>> > have them on your stack, then this means your malloc arena has lots of
>> > unused space.  Decrease the size of your malloc arena by the size of
>> > the environment buffer, and you reach the same goal as with your
>> > patch - actually you save more memory, as the code size of u-boot
>> > shrinks.
>>
>> Em, what you said is also right for my case.
>> But I think making the malloc heap area large while limit the stack usage
>> could benefit those function use malloc, while keep user in mind how many
>> memory he is using on that board. For now, uboot just print uboot self-reserved,
>> malloc size, board info, global data size for the uesr. For the stack usage,
>> user is not quite aware of.
>>
>> Just like the env case, if that ENV_SIZE goes too large, user may not notice
>> the memory usage just from the debug info.
>
> We should pay attention to use the correct terms here. The "user",
> i. e. the end user running the U-Boot image on some system, will most
> probably not bother at all wether you use space on the stack or in the
> malloc arena, or how much.  The only thing that concerns him is that
> the thing "just works".
>
Sorry for the wrong using of "user" term here...

> It is our, the developer's, task, to make sure his expectations are
> met.  And from the robustness and reliability, but also from the
> memory footprint point of view, may favours go clearly with automatic
> variables on the stack over manual allocation.
>
> I mentioned this before: the stack can temporarily use arbitrary
> amounts of storage, whil still allowing you to use a maximum of free
> RAM at other times.
>
> I don't really care how much memory is needed on the stack for
> environment buffers when importing or exporting the environment
> from/to external storage, because this memory is freed again and
> usable for other purposes when I need it, for example to load some big
> OS and/or file system images.  With malloc(), such memory is permantly
> reseverd, and thus permantly lost.

I am a little confused here... Why the malloc would make the memory permantly
reserved and lost... In this patch, I just temp malloc one buffer, then free it
after I use it...

>
> In my opinion this is a clear disadvantage of the malloc() based
> approach.
>
>> My ram is big, 512MB. But for my case, I need uboot use the minimum memory
>> as it can. The debug output is same, for this patch don't change the
>
> Can you please explain your requirements in a bit more detail, and
> especially, how your patch is supposed to help?  I would expect that
> the time when the environment buffers need space on the stack is NOT
> the time when you need so much of memory?
>

My current implementation is to do a memory dump by using the uboot,
while uboot's only task is to compress and write the memory to the sd card.
For the compress and write part need a lot of heap, 350k+, if still keep the
env buf in the stack, it would increase the total memory touched by uboot...

As dump usage need uboot touch the least memory, so this is the purpose
I submit this patch... Reuse the heap area at its best, and don't increase stack
much in the runtime...

Best regards,
Lei