[Top] [All Lists]

Re: [patch] MIPS64 R4k TLB refill CP0 hazards

To: "Kevin D. Kissell" <>
Subject: Re: [patch] MIPS64 R4k TLB refill CP0 hazards
From: Ralf Baechle <>
Date: Wed, 31 Jul 2002 04:05:29 +0200
Cc: Carsten Langgaard <>, "Maciej W. Rozycki" <>,,
In-reply-to: <00f801c237c6$29cabd00$10eca8c0@grendel>; from on Tue, Jul 30, 2002 at 02:39:24PM +0200
References: <> <> <> <> <00f801c237c6$29cabd00$10eca8c0@grendel>
User-agent: Mutt/
On Tue, Jul 30, 2002 at 02:39:24PM +0200, Kevin D. Kissell wrote:

> > following the branch delay slot.  For R4600, R4700, R5000 and a bunch of
> > derivates I've verified that according to the documentation this extra
> > penalty of two cycles does not exist nor we need two extra cycles to handle
> > the hazard.  In other words the branch trick - which also is used by
> > some other commercial OS btw. - is providing best possible performance on
> > a wide range of processors.
> Which would be a fairly compelling argument if (a) we were constrained
> for some reason to only have one handler and (b) the majority of MIPS
> Linux systems being built had R4000/4400/4600/4700/5000 CPUs in
> them.  But neither of those assumptions is true.  I don't see any cases
> in the kernel of assembler functions being put into the .init segment of
> the kernel image, but I would think that it could be (and anyway should
> be) done with the various exception vectors, and in any case they are
> dynamically installed based on the detected CPU.  If people using
> old workstations want to use a branch-based timing hack in their
> TLB handlers, that's all well and good.  But there is no guarantee that
> the trick will work on all future (or even current) MIPS CPUs, and
> I agree with Carsten that it is inappropriate for the generic or default
> MIPS32 handlers.  I guess we need to propose a patch to allow
> the Indy/Decstation crowd to retain their branch-based scheme,
> but to quarantine it from the rest of the MIPS/Linux universe.

Basically we have two groups of interrupt handlers.  Some contain
workarounds for hardware bugs; the rest are very similar except having
to handle different hazards.  I was already thinking about building the
actuall exception handlers from a piece of code that inserts the right
number of (ss)nops etc. as required into the right place, thereby
producing an optimal handler for every CPU.


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