NOMMU: stack versus malloc?

[Mike Frysinger]

On Thursday 11 October 2007, Denys Vlasenko wrote:
> > > > >> For example, lineedit.c currently eats 12k+ if stack.
> > > > >>
> > > > >> I can convert it into malloc use.
> > > > >>
> > > > >> Question: is it better or actually worse?
> > > > >> Line editing is invoked repeatedly, and repeated malloc/free
> > > > >> of random-sized blocks can increase fragmentation
> > > > >> -> increase memory consumption.
> > > > >
> > > > >it really depends on the size of the consumption ... on nommu, the
> > > > > default stack is 4k, so i'd say if you're talking about more than
> > > > > 1k, it should be a malloc ...
> > >
> > > Ick... We have lots of ~4k stack users... and Makefile sets stack to
> > > 20k IIRC, correct me if I'm wrong:
> > >
> > > # Busybox is a stack-fatty so make sure we increase default size
> > > # TODO: use "make stksizes" to find & fix big stack users
> > > # (we stole scripts/checkstack.pl from the kernel... thanks guys!)
> > > FLTFLAGS += -s 20000
> >
> > 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.

i didnt mean it like that ... i meant we cant look at the size and say "we 
have to set it large because busybox is a fatty" and then say "we can have a 
large stack because we increase it"

> > 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?

you can emulate the suite of malloc functions quite trivially with mmap() and 
munmap() and this is called "malloc-simple" in uClibc.  there is a better 
malloc implementation which does larger mmap()'s and then can manage the 
chunks itself to hand out smaller allocations and keep from doing munmap() 
upon a free() and this is called "malloc" in uClibc.

> What happens when you have no brk space because 
> there is another process "above" you?

brk/sbrk do not work on no-mmu ... they're simply not implemented.

> Any URLs to memory management in userspace on NOMMU?

not that i'm aware of ... but there isnt much to it ... you do malloc() and 
you're given a chunk of physical memory.  uClibc alleviates this a bit by 
having an allocator in between the kernel and the application so that smaller 
allocs/frees dont go straight to the kernel to fragment things.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://busybox.net/lists/busybox/attachments/20071013/a35ecfe2/attachment.pgp