Re: memcpy prefetch

[Ralf Baechle <ralf@linux-mips.org>]

On Thu, Apr 07, 2005 at 08:14:06AM -0400, Greg Weeks wrote:

> What's the performance hit for doing a pref on a cache line that is 
> already pref'd?

A wasted instruction.

(More complicated on certain multi-issue in-order processors such as the
SB1 CPU core.  Mentioning this for completeness; we shouldn't worry about
it here.)

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

The smallest D-cache line I know of is 16 bytes.

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

Indeed.  Initially when we started doing such things some people felt it
might be really bad to debug and everything but in practice it's been a
relativly minor problem, so I guess the resistance against yet another
run-time generated group of functions is getting less.

One interesting issue to solve - memcpy, memmove and copy_user are combined
into a single big function, so the fixups for userspace accesses need to
be handled at runtime as well.

  Ralf