Dear Lei Wen,
In message <aanlktin1u7wznvkhoatzkw4uedq1iztlzbo6-qbmo...@mail.gmail.com> you
wrote:
>
> > malloc arena and stack are adjacent. Â If you have enough free room in
> > the malloc arena for the environment buffers, but cannot afford to
> > have them on your stack, then this means your malloc arena has lots of
> > unused space. Decrease the size of your malloc arena by the size of
> > the environment buffer, and you reach the same goal as with your
> > patch - actually you save more memory, as the code size of u-boot
> > shrinks.
>
> Em, what you said is also right for my case.
> But I think making the malloc heap area large while limit the stack usage
> could benefit those function use malloc, while keep user in mind how many
> memory he is using on that board. For now, uboot just print uboot
> self-reserved,
> malloc size, board info, global data size for the uesr. For the stack usage,
> user is not quite aware of.
>
> Just like the env case, if that ENV_SIZE goes too large, user may not notice
> the memory usage just from the debug info.
We should pay attention to use the correct terms here. The "user",
i. e. the end user running the U-Boot image on some system, will most
probably not bother at all wether you use space on the stack or in the
malloc arena, or how much. The only thing that concerns him is that
the thing "just works".
It is our, the developer's, task, to make sure his expectations are
met. And from the robustness and reliability, but also from the
memory footprint point of view, may favours go clearly with automatic
variables on the stack over manual allocation.
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.
In my opinion this is a clear disadvantage of the malloc() based
approach.
> My ram is big, 512MB. But for my case, I need uboot use the minimum memory
> as it can. The debug output is same, for this patch don't change the
Can you please explain your requirements in a bit more detail, and
especially, how your patch is supposed to help? 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: w...@denx.de
The night sky over the planet Krikkit is the least interesting sight
in the entire Universe.
- Douglas Adams _Life, the Universe, and Everything_
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
