linux-mips
[Top] [All Lists]

Re: [patch] blast_scache nop for sc cpus without scache

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [patch] blast_scache nop for sc cpus without scache
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Mon, 27 Jun 2005 16:31:00 +0100 (BST)
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>, Florian Lohoff <flo@rfc822.org>, linux-mips@linux-mips.org
In-reply-to: <20050627143633.GD28082@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20050625131938.GA7669@paradigm.rfc822.org> <20050625160316.GP6953@linux-mips.org> <20050625175048.GA25276@alpha.franken.de> <Pine.LNX.4.61L.0506271309500.15406@blysk.ds.pg.gda.pl> <20050627143633.GD28082@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
On Mon, 27 Jun 2005, Ralf Baechle wrote:

> What matters isn't the presence of a second level cache but the actual
> properties.  The old code was relying almost exclusively on the precense
> of an S-cache, so had to be very liberal in it's assumption about that
> cache's properties.  Performancewise that sucked, badly.

 Well, I do think the defaults for these "features to be overridden" 
should be liberal about accepting what's available.  That is they should 
never take anything for granted.  Performance doesn't matter.  Code has to 
be correct.  It's up to a platform maintainer to tune it if desired and 
possible.

 And if we go back in time for c-r4k.c far enough, then we'll see these 
setup_scache_funcs() and setup_noscache_funcs() functions we used to have 
for proper handling of set-ups both with and without secondary caches.  
There could have been bugs, certainly, but at least the framework was in 
place.

  Maciej

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