Anyone know this paper?

[Joel Sherrill <joel@OARcorp.com>]

gregory.menke at gsfc.nasa.gov wrote:
> "Joel Sherrill <joel at OARcorp.com>" <joel.sherrill at OARcorp.com> writes:
>  > gregory.menke at gsfc.nasa.gov wrote:
>  > > "Joel Sherrill <joel at OARcorp.com>" <joel.sherrill at OARcorp.com> writes:
>  > >  > http://vlsi.ee.duth.gr/amdrel/papers/date04.pdf
>  > >  > 
>  > >  > It is about dynmic memory allocation but I think they
>  > >  > missed the boat on the RTEMS reference.  They appear
>  > >  > to think that the RTEMS region/heap manager is based
>  > >  > on a paper from 2001 which also used the term region.
>  > >  > 
>  > >  > The RTEMS heap design dates back to the earliest days
>  > >  > of RTEMS and certainly predates a paper from 2001.
>  > >  > 
>  > > 
>  > > I think they missed a lot of boats.  Its a pretty superficial
>  > > treatment of memory allocation.  
>  > 
>  > Glad to know it just isn't me being stupid looking at it.
>  > 
>  > Can you even tell what algorithm/data structure they are proposing?
> 
> No, they seemed to spend their time vaporing away about network
> traffic simulations and bitmap twiddling without presenting content-
> or any examples of just how their algorithms help wireless and
> multimedia applications- or any examples of said applications as
> depoyed on embedded systems.  I got the vague impression that they
> implemented a C++ layer on top of the OS heap functions to expose
> their own memory allocation routines.  Then they claimed those big
> percentage "gains" without defintions or data.

Yes.  It is amazing what managing your own free list of
inactive structures of a known type can do for performance. :)

>  No doubt all will
> become clear after they get funding for another round of
> research.. lol ;)

We're not being cynical are we? ;)

>  > > The cites here
>  > > 
>  > > http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/b/Bonwick:Jeff.html
>  > > 
>  > > and also referenced
>  > > 
>  > > http://www.os-help.org/slab_allocators-542520-4686-a.html
>  > > 
>  > > treat the issue exhaustively, from userspace all the way down to
>  > > scalability on SMP systems and cache-friendliness.  I think the people
>  > > who did the paper you identified didn't do enough homework ahead of
>  > > time.
>  > 
>  > Thanks.
>  > 
>  > I believe that there is no perfect algorithm for all real-time
>  > embedded systems.  It would be great to be able to choose from
>  > a variety of heap, CPU scheduling, disk scheduling and disk
>  > caching algorithms based upon your application requirements.
>  > 
>  > It seems that no algorithm is perfect for every situation.
> 
> I agree.  That said, I'm a big fan of the slab concepts, I suppose
> their downside is complexity & subtlety- its great for the user but
> you have to put your software weenie hat on to understand what its
> doing inside.

I am not opposed to replacing the supercore heap or making the
malloc family use a different algorithm.

> Gregm
> 
> 


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