[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: NOMMU: stack versus malloc?
From:       Mike Frysinger <vapier () gentoo ! org>
Date:       2007-10-13 19:02:50
Message-ID: 200710131502.51519.vapier () gentoo ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 11 October 2007, Johan Adolfsson wrote:
> 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?)

the userspace overhead in "malloc-simple" should be sizeof(size_t) per 
allocation and that's it ... this implementation used to be the default for 
no-mmu in uClibc, but no longer ...

the overhead of "malloc" will be more as it maintains link lists, but it'll be 
a lot better as it maintains the heap rather than the kernel

> * 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.

the default allocator in the kernel is a power of two, but things are moving 
to make this not so bad ... not sure what SLUB brings to the table, but that 
is one of the features of SLOB over SLAB.  in the end though, fragmentation 
is a bitch.
-mike

["signature.asc" (application/pgp-signature)]

_______________________________________________
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox

[prev in list] [next in list] [prev in thread] [next in thread]