Re: [PATCH] x86: create array based interface to change page attribute

["Thomas Hellström" <thomas@tungstengraphics.com>]

Andi Kleen wrote:
> On Mon, Mar 31, 2008 at 11:06:16AM +0200, Thomas Hellström wrote:
>   
>> Andi Kleen wrote:
>>     
>>>> Also I think we need to clarify the semantics of the c_p_a 
>>>> functionality. Right now both AGP and DRM relies on c_p_a  doing an 
>>>> explicit cache flush. Otherwise the data won't appear on the device side 
>>>> of the aperture.
>>>>    
>>>>         
>>> But surely not in cpa I hope ? Or are you saying you first write data
>>> and then do cpa? If true that would be quite an abuse of CPA 
>>> I would say and you should fix it ASAP.
>>>
>>>  
>>>       
>> As AGP buffers are moved in- and out of AGP, the caching policy changes, 
>> so yes, there may be writes to cache coherent memory that needs to be 
>> flushed at some point. Since CPA has been doing that up to now, and the 
>> codepaths involved are quite time-critical, a double cache-flush is a 
>>     
>
> That doesn't make sense. You shouldn't be using CPA in any 
> time critical code path. It will always be slow. 
>
> For anything time critical you should keep a pool of uncached pages 
> once set up using CPA and reuse them.
>
> CPA really should only be used on initialization or for
> larger setup changes which are ok to go somewhat slower.
>   
Let me rehprase. Not really time-critical but it is of some importance 
that CPA is done quickly.
We're dealing with the tradeoff of reading from uncached device memory 
vs taking the pages out of
AGP, setting up a cache-coherent mapping, read and then change back. 
What we'd really would like to set up is a pool of completely unmapped 
(like highmem) pages. Then we could, to a large extent, avoid the CPA calls.

>
>
> The cache must be flushed in CPA, there is no way around it.
>
> If you write data into the buffers before you do CPA on them
> you could avoid it, but I don't think you should do that anywhere
> near time critical code, so it actually shouldn't matter.
>
> -Andi
>   
But then we wouldn't really be discussing SS either? For DRM purposes, 
the more performance we can squeeze out of CPA, the better.

/Thomas