[U-Boot] [RFC][PATCH] Update malloc to dlmalloc version 2.8.4
Mike Frysinger
vapier at gentoo.org
Wed Jul 8 20:57:28 CEST 2009
On Wednesday 08 July 2009 02:58:42 Peter Tyser wrote:
> Robin Getz wrote:
> > On Wed 8 Jul 2009 01:58, Mike Frysinger pondered:
> >> On Tuesday 07 July 2009 18:24:56 Kumar Gala wrote:
> >>> On Jul 7, 2009, at 3:25 PM, Scott Wood wrote:
> >>>> Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>>> On 15:02 Tue 07 Jul , Scott Wood wrote:
> >>>>>> Kumar Gala wrote:
> >>>>>>> Those would help if the data structs had gotten bigger. In this
> >>>>>>> case the code itself is just larger.
> >>>>>>
> >>>>>> Perhaps we should look into using/writing a malloc implementation
> >>>>>> that takes a space/speed tradeoff more in line with U-boot's
> >>>>>> requirements (using a simple first-fit linear scan of free blocks,
> >>>>>> for example) -- and hopefully more readable than dlmalloc?
> >>>>>>
> >>>>>> I nominate those with the tightest space requirements to do
> >>>>>> this. :-)
> >>>>>
> >>>>> I agree it's sound a better plan
> >>>>> but I'll take a lot's of time
> >>>
> >>> Do we think there is some other project that we can acquire one from?
> >>
> >> there was another public domain malloc implementation Robin pointed me
> >> to recently, but i cant seem to remember/find it.
> >
> > It was bget
> >
> > http://www.fourmilab.ch/bget/
>
> The CFE bootloader has a pretty simple malloc implementation. It looks
> relatively readable and is much smaller than dlmalloc:
>
> ptyser at petert cfe$ size cfe30/lib_malloc.o
> text data bss dec hex filename
> 1128 4 0 1132 46c cfe30/lib_malloc.o
>
> http://www.broadcom.com/support/communications_processors/downloads.php
>
> Some other liberally licensed bootloaders such as PMON2000 might have
> some basic implementations too.
it's trivial to find smaller implementations. i guess the problem we have is
that we dont have any guidelines for what we want out of a malloc
implementation. i would bet that dlmalloc fairs better than these simple
implementations wrt fragmentation, re-use, and freeing. but if our typical u-
boot usage does little malloc/free, then this better behavior doesnt really
matter to us.
does dlmalloc have any compile time knobs to help direct the functionality
actually desired ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090708/7eec9f4b/attachment.pgp
More information about the U-Boot
mailing list