RFC : Heap management using TLSF

[Joel Sherrill]

Tim wrote:
>> 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
>
>   
LOL! That's only 4 years old so I can't see that much changed
since then.  It was released on 2004-04-08.

FWIW the last 4.5 public tarball was released 2001-10-17 and
there is a 3.2.1 on the ftp site which was released 1995-08-15.
We have QIC-150 tapes around the office which should have
1.x versions of RTEMS.  Next year will mark 20 years since I
first worked on RTEMS.
> 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 :)
>
>   
Great and with Pavel pointing out that the license changed, it
sounds like something for 4.10.
> 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