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