more cache manager issues

[Nick.SIMON at syntegra.bt.co.uk]

I've been following this thread with some interest, having recently got
caching working on our MPC860 card.  It seems to me that all the approaches
suggested so far are problematic in onw way or another.

 - Cache-aligning all allocations is very wasteful, especially with CPUs
with bigger cache lines.

 - Having special alloc/free routines is error prone (and also leads to heap
fragmentation).

 - Virtualising free in the block header could lead to some spectacular
crashes!

 - Having a separate region for cache-aligned allocation means you have to
partition your memory in your design, inevitably causing waste.

Might it not be better to deal with these issues in the relevant drivers?
They could allocate an extra cache lines worth and pick the hardware buffers
on a cache-aligned address within the allocated block.  There aren't too
many places where this is done and IMHO it's a bad reason to completely
upturn memory allocation for everything else.


-- Nick Simon 

> -----Original Message-----
> From: Joel Sherrill [mailto:joel.sherrill at OARcorp.com]
> Sent: 31 October 2000 21:35
> To: Eric Norum
> Cc: Till Straumann; rtems-users at oarcorp.com; Joel Sherril
> Subject: Re: more cache manager issues
> 
> 
> Eric Norum wrote:
> > 
> > Till Straumann wrote:
> > 
> > > An alternative to this approach would be letting
> > > rtems_cache_aligned_malloc()
> > > using its own heap with a bigger (cache aligned) granularity.
> > 
> > Yes, but now there's another configuration parameter to be 
> dealt with.
> > Deciding on where to split the heaps adds more of a burden to the
> > application programmer.
> > 
> > >
> > > One global `free(arg)' function could then determine the heap
> > > corresponding to the argument
> > > by comparing the argument pointer to the standard heap / 
> aligned heap
> > > starting and end addresses.
> > >
> > > Even more elegant would of course be an object oriented 
> approach with a
> > > virtual `free' member
> > > function (or a field in the block header holding the 
> information about
> > > which version of `free' must
> > > be used for that specific block of memory).
> > 
> > Yep.  Maybe the memory allocation routines (both regular and cache
> > aligned) should be rewritten to do this.
> 
> FYI the way the heap code is designed the minimum block size 
> is 4 bytes
> or 1 unsigned32 and allocations are always multiples of 4.  
> If you look 
> closely you will see the least significant bit of the front/back flags
> is used as an indicator of used/free.  It is possible that the next
> bit could indicate cache aligned allocation or not.  I don't know if
> this
> helps or not.
> 
> ALso -- there is NOTHING preventing the entire replacement of the 
> libc/malloc code.  There is nothing sacred about the use of a
> region.  It was just convenient.  The region is implemented to the
> RTEID/ORKID specification, there is almost certainly a better
> malloc implementation for embedded systems.
> 
> > >
> > > IMHO, the need to call a `special' deallocator function 
> is very error
> > > prone.
> > 
> > Agreed.
> > My quick solution to the problem wasn't very good.
> > 
> > I'm not yet convinced that dual heaps is a good idea, though.
> > 
> > --
> > Eric Norum                                 eric at cls.usask.ca
> > Canadian Light Source                      Phone: (306) 966-6308
> > University of Saskatchewan                 FAX:   (306) 966-6058
> > Saskatoon, Canada.
> 
> -- 
> 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
>