Dear Graeme Russ, In message <AANLkTi=--aNmH1H0JbUFgcW+qL3qeHvOzb9CcUA=p...@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: w...@denx.de Peace was the way. -- Kirk, "The City on the Edge of Forever", stardate unknown _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot