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