Re: memcpy prefetch

[Greg Weeks <greg.weeks@timesys.com>]

Ralf Baechle wrote:

>On Wed, Apr 06, 2005 at 08:30:52AM -0400, Greg Weeks wrote:
>
>  
>
>>In trying to understand the prefetch code in memcpy it looks like it's 
>>prefetching too far out in front of the loop. In the main aligned loop 
>>the loop copies 32 or 64 bytes of data and the prefetch is trying to 
>>prefetch 256 bytes ahead of the current copy. The prefetches should also 
>>pay attention to cache line size and they currently don't. If the line 
>>size is less than the copy size we are skipping prefetches that should 
>>be done. For the 4kc the line size is only 16 bytes. We should be doing 
>>a prefetch for each line. The src_unaligned_dst_aligned loop is even 
>>worse as it prefetches 288 bytes ahead of the copy and only copies 16 or 
>>32 bytes at a time.
>>
>>Have I totally misunderstood the code?
>>    
>>
>
>Nope, you've understood that perfectly right.  The messy thing is that on
>a whole bunch of system we don't know the cacheline size before runtime
>so we have two choices a) work under worst case assumptions which would be
>16 bytes.  Or do the same thing as we're already doing it for a bunch of
>other performance sensitive functions, generating them at runtime.  Choose
>your poison ;-)
>  
>
What's the performance hit for doing a pref on a cache line that is 
already pref'd? Does it turn into a nop, or do we get some horrible 
degenerate case? Are 64 bit processors always at least 32 byte cache 
line size? I don't really expect anyone to know the answers right now. I 
expect I'll need to time code to tell. This makes generating them at run 
time look better and better.

Greg Weeks