rob at landley.net
Tue Aug 30 02:27:27 UTC 2005
Ah, top quoting. The sign somebody's been dealing with traditional business
types used to stapling their reply to the top of the previous document and
throwing it in the "out" tray...
On Monday 29 August 2005 20:23, Jason Schoon wrote:
> Especially given that we provide a configuration option for allocating in
> either .bss, heap, or stack (although I'm not sure how well it has been
Not very. Going through and cleaning that up is in the current TODO.
> I would think we wouldn't want to start blindly allocating on
> the stack. I have been on many embedded systems with 2k or smaller stacks.
> They are a pain all around, but it seems as though Busybox has at least
> made a partial attempt to address this.
At one time it did, but not so much recently. The only testing we've gotten
is on the linux kernel, and that doesn't have stacks that constrained. (Not
even the nommu variants.)
Shaun Jackman's newlib work is the closest we've come to running in a
non-linux environment in the past few years.
> I agree the cleanup is a mess though. atexit() is a great idea for the most
> part, although as you said, it is not immediate reclaming of space. If
> somebody cares at all about this cleanup stuff, rather than just letting
> the memory be return automatically, they probably want it returned as soon
> as possible.
> Ugh. Memory limitations are a pain.
Memory limitations are what busybox is all about. One of the things, anyway.
But there are at least three different _types_ of memory limitations in play
here. Executable size, heap size, and stack size. And a lot of the
optimizations we can make are mutually exclusive.
What we've _been_ optimizing recently is executable size first (since flash
and running from a CD are generally a lot more constrained than dram, and
saving executable bytes saves the dram it would be loaded into as well),
followed by saving heap space.
Allocating on stack means you save two function calls per allocation (the
malloc() and the free()), plus memory never leaks, plus you don't have to
worry about heap fragmentation, plus you don't need the data structures used
to keep track of heap fragments (saves space _and_ time; malloc in a tight
loop can slow you down quite a bit even without taking cache non-locality
It has a lot to recommend it. And there are systems out there with 4k stacks
where this just isn't an option, but do we run on those now, and are we
interested in doing so?
More information about the busybox