From mboxrd@z Thu Jan  1 00:00:00 1970
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 27 Jan 2009 23:09:22 +0000 (GMT)
Received: from mail3.caviumnetworks.com ([12.108.191.235]:61983 "EHLO
	mail3.caviumnetworks.com") by ftp.linux-mips.org with ESMTP
	id S21103024AbZA0XJU (ORCPT <rfc822;linux-mips@linux-mips.org>);
	Tue, 27 Jan 2009 23:09:20 +0000
Received: from exch4.caveonetworks.com (Not Verified[192.168.16.23]) by mail3.caviumnetworks.com with MailMarshal (v6,2,2,3503)
	id <B497f93f60000>; Tue, 27 Jan 2009 18:08:38 -0500
Received: from exch4.caveonetworks.com ([192.168.16.23]) by exch4.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Tue, 27 Jan 2009 15:07:45 -0800
Received: from dd1.caveonetworks.com ([64.169.86.201]) by exch4.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Tue, 27 Jan 2009 15:07:45 -0800
Message-ID: <497F93C1.3090401@caviumnetworks.com>
Date:	Tue, 27 Jan 2009 15:07:45 -0800
From:	David Daney <ddaney@caviumnetworks.com>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To:	Michael Sundius <msundius@cisco.com>
CC:	linux-mips@linux-mips.org, "VomLehn, David" <dvomlehn@cisco.com>,
	msundius@sundius.com
Subject: Re: memcpy and prefetch
References: <497F9214.1000609@cisco.com>
In-Reply-To: <497F9214.1000609@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Jan 2009 23:07:45.0622 (UTC) FILETIME=[10925F60:01C980D4]
Return-Path: <David.Daney@caviumnetworks.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 21848
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ddaney@caviumnetworks.com
Precedence: bulk
X-list: linux-mips

Michael Sundius wrote:
> I know this topic has been written about but so excuse me if I am 
> redundant.
> I saw lots of talk in the archives but I don't know if a solution was 
> ever arrived
> at. so:
> 
> what is the current state of the use of prefetch in memcpy()? it seems that
> it is #undef-ed if CONFIG_DMA_COHERENT is not turned on.
> 
> is this still because the memcpy does not check to prevent a prefetch of
> addresses beyond the end of the buffer?
> 
> If so, what was the reason a solution was abandoned....
> 
> also  has anyone out there written a memcopy that does use prefetch
> intelligently (for mips32 that is)?
> 

The Cavium OCTEON port overrides the default memcpy and does use 
prefetch.  It was recently merged (2.6.29-rc2).  Look at octeon-memcpy.S

I have thought that memcpy could be generated by mm/page.c as copy_page 
and clear_page are.

David Daney