From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [U-BOOT] [PATCH] env: reduce the stack footprint for the env buf
Date: Sun, 06 Feb 2011 17:08:44 +0100 [thread overview]
Message-ID: <20110206160844.AB4CBEC91BD@gemini.denx.de> (raw)
In-Reply-To: <AANLkTin1U7WZnVKhOaTzkW4UEDQ1iZtLZBo6-qBMoUzY@mail.gmail.com>
Dear Lei Wen,
In message <AANLkTin1U7WZnVKhOaTzkW4UEDQ1iZtLZBo6-qBMoUzY@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: wd at 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_
next prev parent reply other threads:[~2011-02-06 16:08 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-04 3:08 [U-Boot] [U-BOOT] [PATCH] env: reduce the stack footprint for the env buf Lei Wen
2011-02-04 20:31 ` Scott Wood
2011-02-04 21:18 ` Wolfgang Denk
2011-02-05 1:21 ` Lei Wen
2011-02-05 8:30 ` Wolfgang Denk
2011-02-05 9:33 ` Graeme Russ
2011-02-05 14:11 ` Wolfgang Denk
2011-02-06 15:25 ` Lei Wen
2011-02-06 16:08 ` Wolfgang Denk [this message]
2011-02-07 4:38 ` Lei Wen
2011-02-07 5:04 ` Graeme Russ
2011-02-07 7:06 ` Wolfgang Denk
2011-02-07 6:58 ` Wolfgang Denk
2011-02-07 8:17 ` Lei Wen
2011-02-07 8:59 ` Wolfgang Denk
2011-02-07 9:01 ` Lei Wen
2011-02-07 9:43 ` [U-Boot] Compiler Question Maik Hänig
2011-02-07 10:17 ` Wolfgang Denk
2011-02-07 10:24 ` Maik Hänig
2011-02-07 11:41 ` Wolfgang Denk
2011-02-07 12:03 ` Maik Hänig
2011-02-07 13:10 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110206160844.AB4CBEC91BD@gemini.denx.de \
--to=wd@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox