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

[Wolfgang Denk <wd@denx.de>]

Dear Graeme Russ,

In message <AANLkTi=--aNmH1H0JbUFgcW+qL3qeHvOzb9CcUA=PX-B@mail.gmail.com> you wrote:
>
> > 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...
> 
> Ah, so with the env buffer on the stack, the bottom of the stack is being
> pushed into the memory you want to dump and corrupting it - Makes sense to
> me now that you would resort to moving the env buffer to the heap.

No, this makes zero sense, as there is only a single time when the
environment buffers are allocated on the stack, and this is very
early in the initialization, and then the buffers are released and
will never be used again - they are gone without any trace when Lei
Wen can run any of his code.  On the other hand, it sounds as if he ad
a huge malloc arena, which is statically reserved and thus unusable
for other pruposed for the whole U-Boot run time.

> There are probably a number of other areas in u-boot where large buffers
> are put on the stack while the malloc pool is relatively empty with the
> end result being that u-boot is using more memory than strictly required.
> 
> It would be an interesting profiling excercise

Indeed there is probably potential for optimization - but usually it's
the other way round: using buffers on the stack is frequently what
results in smaller code and a smaller overall memory footprint; not to
mention the issue of memory leaks when using malloc().


I seriously doubt that Lei Wen as able to show any improvement of the
memory footprint by his code.  In the best case, he already has
reserved a huge malloc arena so the environment buffers can be
allocated there.  In this case, the overall effect of his patch is the
increased code size which _reduces_ the free memory on his system.

He does NOT save any memory on the stack, because the
env_relocate_spec() simply never ever gets called when he is running
his code.

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
Peace was the way.
	-- Kirk, "The City on the Edge of Forever", stardate unknown