RFC : Heap management using TLSF

[Tim]

> Tim wrote:
> > On Tue, 2008-07-29 at 08:25 -0500, Joel Sherrill wrote:
> >> I would like to make sure I understand why this algorithm
> >> is better.  And we definitely want to ensure that we have
> >> the same type of statistics and error checking information
> >> available in TLSF.  It would also be great to be able to walk the heap
> >> and get other information via the RTEMS gdb macros.
> >
> > Yeah, no problem :)
> >
> > I'll be honest, I was talked into TLSF when I got back from 2 months of
> > holiday this year, having missed the previous discussion that took
> > place, so I basically put my hand up to do the work.
> >
> > I've had a stab at transplanting TLSF into the tree, and we're using it
> > on a development branch, and giving it as much exposure as we can - no
> > problems so far.
> >
> > The transplant includes stats, 95% complete. No GDB macros as yet
> > though.
>
> So you really are up to the license being a problem.
>
> For GDB macros, ideally we would have some statistics
> and heap integrity walker as gdb macros.  So they don't
> depend on anything except accessing target memory.
>
> >> With any luck, the limited way the heap API is easy enough to just
> >> replace with another implementation.
> >>
> >> The only other gotcha in this is that the Classic API Region
> >> and ITRON API memory pools use the heap so we have to
> >> be sure we get the published features on those.
> >>
> >> Basically you are looking to replace code that has already
> >> been overhauled once in the life of RTEMS but we have
> >> a fair amount of aids and APIs built around it, so we don't
> >> want to lose any capabilities.
> >
> > Understood. In a couple of weeks I'll be back on this, and first thing
> > will be some benchmarks to quantify any performance gains associated
> > with moving to TLSF.
>
> Great.
>
> One thing I don't think got emphasized enough in my
> response is that "the heap code has already been overhauled
> once in the life of RTEMS."  That means that it is a fairly
> well contained subsystem.  If you are working with CVS
> (please say yes), then the malloc family has had a lot
> of work for cleanup.
>

Actually 4.6.1

Just kidding. We're working with rtems-4-8-branch at the moment, so that's 
where our local TLSF lives atm. That said, I intend to move us to 4.9 within 
the next month, all going well.  The TLSF code was pretty trivial to insert as 
a replacement backend, including metrics, so the existing subsystem should 
remain mostly intact. I'll consult you plenty when the time comes anyways :)

Cheers,
Tim