more cache manager issues

[Till Straumann]

Nick.SIMON at syntegra.bt.co.uk wrote:

> 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!
>

why should it? BTW we are only talking about `pseudo-virtualization', i.e.
free() needn't really do an indirect function call through a full blown virtual

member function table. Rather, it could directly call the correct version
of lowlevel-free itself, based on information in the block header (which is
invisible to the user). Since the only ones messing with the block header
are the different allocators  (normal and cache-aligned) and the single
free(), there's no reason why it should produce spectacular crashes. Unless
somebody corrupts the block headers - but in this case you are likely to
have spectacular crashes anyway.

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

Well, the solution suggested by Nigel Spon (posted yesterday on this list)
is a possible way to avoid this.

>
>
> 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.
>

It seems to me that this pretty much comes down to the `dedicated
allocator/deallocator'
approach. The problem being, that you can not, in general, assume that the
memory
you allocate in the driver code will also be deallocated there. Buffers may be
allocated
by a driver and then passed to an upper software layer and eventually be
free()ed upstream.

Your suggestion would either require copying the data before passing it on or
tracking
the data flow and make sure that the correct deallocator is called (most likely
in a different
software module).

That's why the (pseudo) virtual `free'  is so important. The code that releases
a block of
memory needn't know which kind of memory it's dealing with.

-- Till.

>
> -- Nick Simon