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

[Lei Wen]

Hi Wolfgang,

On Mon, Feb 7, 2011 at 2:58 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Lei Wen,
>
> In message <AANLkTim4-Nny184WXzcspcAEtAeSe8+M4y08B3aLJtYw at mail.gmail.com> you wrote:
>>
>> > 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...
>
> Yes, you free it, so it becomes usable for other malloc() calls
> (eventually - in real life fragmentation might play a role, too),
> but you sneed to reserve the full emount of buffer space in the malloc
> arena, for the whole like time of U-Boot.
>
> On the othern hand, when using buffers on the stack, then these
> buffers are only temporarily used, when the functions are actually
> being called. In this specific case (keep in mind that we are talking
> about env_relocate_spec() this happens exactlky once, very early in
> the system initialization, i. e. long before you are able to run any
> user commands.
>
>> 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...
>
> This statement makes no sense at all.  The environment buffers are
> only used once, long before you are able to run any user commands.
> Wehn you can start doing your stuff, they are long gone, and all of
> it's memory has been reclaimed.
>
>> 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...
>
> But it statically increases the size of the malloc areane, so you are
> just shifting the memory from location A to B.
>
>
> For the last time I repeat my question: can you please explain how
> your patch is supposed to reduce the memory footprint of your system,
> and document your acchievments with actual measurements? 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?
>

The measurement is simple, for I don't change other part, the heap
size and etc part
size, but only move the temp buffer to the heap area instead of stack area.
So this reduce the large memory need in the env_relocate_spec() function.
So that the stack would not touch those memory since most function
don't cost so much
stack as env_relocate_spec() does...

Also what you said for it is not the same time to different function
usage is also true here.
But what I want this patch is for I want the uboot touch the minimum
memory, not others...

The heap area is already enough for the env_relocate_spec() in our
platform. Maybe
you concern is for those platform don't allocate enough heap size for
the env?...
Also fragmentation problem I am not figure out clearly... Temporarily
use large heap then free
would make uboot unable to malloc enough memory in latter allocate?...

Best regards,
Lei