Comments on svn 16057.

Rob Landley rob at landley.net
Thu Sep 7 00:33:29 UTC 2006


On Wednesday 06 September 2006 4:40 pm, Bernhard Fischer wrote:
> On Wed, Sep 06, 2006 at 01:51:36PM -0400, Rob Landley wrote:
> >http://busybox.net/downloads/patches/svn-16057.patch
> >
> >RESERVE_CONFIG_BUFFER() is actually a bit of a dinosaur.  It turns out that 
> >most of the times I've tested, declaring a pointer and using xmalloc() (or 
> >xzalloc()) actually results in smaller code.  (On x86 anyway.)  And the 
only 
> >reason for declaring stuff on the stack was that it was theoretically 
> >smaller...
> >
> >And in this particular case, xzalloc() saves the calls to memset().
> >
> >I'm considering removing RESERVE_CONFIG_BUFFER() and just using malloc() 
when 
> >it makes sense and declaring stuff on the stack when it makes sense.  
Anybody 
> >have any opinions on this?  If nothing else it simplifies the code...
> 
> Well, theoretically, mem-constrained setups want to avoid malloc, so
> empowering the user to decide to use malloc or stack or bss is the most
> flexible thing to provide.

If it's a nommu setup, then throwing extra stuff on the stack is actually 
worse because they have a fixed size stack they need to preallocate.  The 
main downside of nommu malloc is fragmentation, so ideally it just wants to 
malloc once, up front, and then not have to do so again during the run.  But 
repeated malloc is possible for nommu to do (and small allocations are fairly 
likely to work, it's finding big contiguous chunks that's a bit of a pain but 
you have to do that to exec a new process _anyway_ so it's not like we're 
inventing new problems here), and arbitrarily growing the stack is not.

> Taking away that possibility needlessly 
> cripples busybox for no (apparent, at least for /me) benefit.

We have somewhere north of 200 applets today.  Even BusyBox 0.60 had well over 
100.  "find . -name '*.c' | xargs grep CONFIG_BUFFER | wc" finds 37 
instances, several of which are in the same applets.

Define "cripples".

> From my POV it's not a dinosaur but the proper way to let folks decide the
> strategy best suited for their target..

It's three different codepaths to debug, in the part of the code (memory 
allocation) that's pretty much always the nasty part when you're dealing with 
C, and when I attempted to measure the actual savings I found it to be 
_negative_ in terms of code size.  (Dunno about runtime memory usage, but the 
same effect could be gotten by grouping several different chunks of memory 
into a single allocation, which things like bunzip2 already do.)

I do want to improve our memory situation, specifically I want to group 
together our statics into the global structures I talked about earlier.  But 
this "I dunno if it's on the stack or on the heap, and I dunno of 
sizeof(object) gives me the size of the allocation or the size of the pointer 
to the allocation."  Plus there are funky corner cases having to do this 
giving us a char * and sometimes we want a struct or some such and thus we 
declare a second pointer to assign it to so we can typecast.  (And when we 
don't we get signedness issues.)  And it gets _really_ fun if we pass one of 
these to a function that realloc()s the buffer and it works when we test it 
because we didn't try the on-stack codepath...

Now if there's a concrete benefit that's worth all this, I'd love to hear it.  
But this has been in the tree for years and its penetration is pretty darn 
small, and when I looked I found an anti-benefit.  Do you have better numbers 
than I do?  How do I test to see a benefit?

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list