Re: mmap nocache on PPC, 2.4

[Stephen Williams <steve@icarus.com>]

Stephen Williams wrote:
> Dan Malek wrote:

> | Even if this did what you thought it should, I'm not sure you
> | would be happy with the results.  The challenge is ensuring
> | anyone that touches these physical pages also does so
> | uncached.  Depending upon the processor, this isn't something
> | that is trivial to change in the kernel, since we always map
> | all of memory as efficiently as possible with a cached mapping.
> | The caching of memory has many desirable performance
> | side effects, making the trade off the manage coherency in
> | software if needed an overall system gain.
> 
> The processor is touching this memory only very briefly to put
> image headers around the data, and even at that it would need
> to be immediately flushed again so that it can be DMAed off the
> system.
> 
> My problem is that I need a lot of memory that is mostly accessed
> by high performance devices that make lots of data, and only
> very occasionally accessed by the processor for minor fixups.
> Caching is very much getting in my way here in this specialized
> case, I think.

I would like to add that it is not exactly the cache that is
getting in my way, but *cache invalidation*. For the tests I'm
running the destination buffer is 16Meg. The PPC405GPr 266MHz
is taking 10ms to invalidate the cache for all that memory and
another 6ms to "map" it and get physical addresses for DMA, but
I need it to be turned around in more like 1ms.

Of the 16ms to turn the buffer around, I've eliminated 10ms
simply by treating the memory of the buffer as uncached. I'm
hoping to work on the remaining 6ms by premapping where I can.


-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."