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

[Wolfgang Denk]

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?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Generally speaking, there are other ways to accomplish whatever it is
that you think you need ...                               - Doug Gwyn