Hi Wolfgang, On Mon, Feb 7, 2011 at 2:58 PM, Wolfgang Denk <w...@denx.de> wrote: > Dear Lei Wen, > > In message <aanlktim4-nny184wxzcspcaetaese8+m4y08b3alj...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot