From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Apr 2005 15:05:42 +0100 (BST) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:2321 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 7 Apr 2005 15:05:14 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j37E586C016582; Thu, 7 Apr 2005 15:05:09 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j37E57UV016581; Thu, 7 Apr 2005 15:05:07 +0100 Date: Thu, 7 Apr 2005 15:05:07 +0100 From: Ralf Baechle To: Dominic Sweetman Cc: Greg Weeks , linux-mips@linux-mips.org Subject: Re: memcpy prefetch Message-ID: <20050407140507.GA4948@linux-mips.org> References: <4253D67C.4010705@timesys.com> <20050406200848.GB4978@linux-mips.org> <4255240E.4050701@timesys.com> <16981.10097.547098.639380@arsenal.mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16981.10097.547098.639380@arsenal.mips.com> User-Agent: Mutt/1.4.1i Return-Path: 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: 7628 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: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Apr 07, 2005 at 01:28:33PM +0100, Dominic Sweetman wrote: > Greg Weeks (greg.weeks@timesys.com) writes: > > > 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? > > The specification for the prefetch instruction is fairly wide, to > permit different implementations to act differently. It's perfectly > legal for it to be a no-op. The R5000 series actually treats it as a nop - which is why Linux treats the R5000 as a CPU that does not have prefetch. > However, implementors are told that they > should not do anything which would make performance *worse* than if it > was a no-op. Okay, but that should be obvious, I'd hope :-) > > Are 64 bit processors always at least 32 byte cache line size? > > There's no reliable correlation. If you were to go round the > "autogenerated at kernel-startup-time" route, then you can figure out > the line size from the "Config" registers (MIPS32- or MIPS64-compliant > CPUs) or from a table of CPU IDs or otherwise (earlier CPUs)... Linux already contains a huge chunk of code to detect these and many more cache properties for mips32, mips64 and more. We also try to make sure the compiler can do constant folding etc. as far as possible for a particular platform. All it takes is a suitable cpu-feature-overrides.h. In absence of that Linux will built cache that pretty much support everything in the universe - at some code bloat. Ralf