NOMMU: stack versus malloc?

Johan Adolfsson Johan.Adolfsson at axis.com
Thu Oct 11 05:56:15 PDT 2007


> > we set the stack to 20k because of all the fatty stack 
> buffers ;) ... so this 
> > is a chicken & egg argument
> 
> Argument? I'm not trying to argue here, I am trying to understand
> the situation with stack usage on NOMMU front before I go and
> "fix" stuff which maybe doesn't need fixing.
> 
> > thinking about it more, fragmentation tends to be a much 
> worse issue on no-mmu 
> > than OOM, so allocating/freeing small buffers over the 
> place would be 
> > nasty ...
> 
> How malloc works on NOMMU? What happens when you have no brk 
> space because
> there is another process "above" you? Any URLs to memory management
> in userspace on NOMMU?
> --
> vda

Sorry, no pointers but here are some thoughts I hopefully recall correctly 
from the time before our chip got an MMU and we used NO_MMU uClinux and
uClibc.
Things may have improved a lot since then so take it with a grain of salt:

* uClibc has/had a few different allocator implementations
* I believe we used the one where each malloc() goes to the kernel to 
  allocate a chunk. The overhead of each allocated memory chunk was fairly
high 
  (32 bytes?)
* Fragmentation is a bitch - use the stack if you can. 
  If the page size is X, it was better to allocate X-overhead to avoid using

  two pages if you dont really need the exact amount.

If you normally only need a small amount of memory I would say: 
First have a small buffer on the stack - if more is needed use malloc().
That will probably cost a few extra bytes of code, but may be worth it in 
terms of smaller normal stack usage and less fragmentation.

Could possibly be implemented something like this:
char staticbuf[BUF_SIZE];
char *buf = staticbuf;

buf = buf_realloc(buf, newsize, staticbuf);
buf_free(buf, staticbuf);
where buf_realloc() and buf_free() compares buf and staticbuf and does the
right thing (i.e. malloc() instead of realloc if buf == static 
and no free if buf == staticbuf.

Some macro magic might hide the ugly details and make the behaviour 
controlled by config options.

/Johan



More information about the busybox mailing list