linux-mips
[Top] [All Lists]

Re: memcpy prefetch

To: Greg Weeks <greg.weeks@timesys.com>
Subject: Re: memcpy prefetch
From: Ralf Baechle <ralf@linux-mips.org>
Date: Thu, 7 Apr 2005 13:25:04 +0100
Cc: linux-mips@linux-mips.org
In-reply-to: <4255240E.4050701@timesys.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <4253D67C.4010705@timesys.com> <20050406200848.GB4978@linux-mips.org> <4255240E.4050701@timesys.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4.1i
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

<Prev in Thread] Current Thread [Next in Thread>