linux-mips
[Top] [All Lists]

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

To: "Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: [patch] blast_scache nop for sc cpus without scache
From: Ralf Baechle <ralf@linux-mips.org>
Date: Mon, 27 Jun 2005 16:36:33 +0200
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>, Florian Lohoff <flo@rfc822.org>, linux-mips@linux-mips.org
In-reply-to: <Pine.LNX.4.61L.0506271309500.15406@blysk.ds.pg.gda.pl>
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>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4.1i
On Mon, Jun 27, 2005 at 01:45:39PM +0100, Maciej W. Rozycki wrote:

>  Anyway these days we apparently ignore the result of the S-cache probe 
> and the sc_present variable.  The only values that determine whether an 
> S-cache is present or not are: cpu_has_dc_aliases, cpu_has_ic_fills_f_dc 
> and cpu_has_subset_pcaches which you need to get right for your 
> configuration -- I guess cpu_has_dc_aliases == 0, cpu_has_ic_fills_f_dc == 
> 1 and cpu_has_subset_pcaches == 0 should be right to fulfil your needs 
> (but it may break elsewhere).  Have I heard: "serious brain damage" from 
> you?  Well, I couldn't agree more...

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.

  Ralf

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