RFC : Heap management using TLSF

Joel Sherrill joel.sherrill at OARcorp.com
Thu Jul 31 16:10:28 UTC 2008


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. 
> Cheers,
> Tim
>
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985





More information about the users mailing list