linux-mips-fnet
[Top] [All Lists]

Re: [patch] MIPS64 R4k TLB refill CP0 hazards

To: "Kevin D. Kissell" <kevink@mips.com>
Subject: Re: [patch] MIPS64 R4k TLB refill CP0 hazards
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Wed, 31 Jul 2002 13:49:57 +0200 (MET DST)
Cc: Ralf Baechle <ralf@oss.sgi.com>, Carsten Langgaard <carstenl@mips.com>, linux-mips@fnet.fr, linux-mips@oss.sgi.com
In-reply-to: <005001c23863$e077caa0$10eca8c0@grendel>
Organization: Technical University of Gdansk
On Wed, 31 Jul 2002, Kevin D. Kissell wrote:

> I really don't think that's a good idea.  That implies that we
> could no longer simply inspect the exception handlers in
> the source code or disassembled kernel binary file to 
> analyse them for correctness, and I think it would lead
> to unnecessary and hard-to-find bugs.  My personal
> recommendation would be to keep the model we have
> today, wherein handlers are selected at boot time from
> some set of candidates built into the kernel binary, with

 Well, as long as we don't have an insane number of variations (say 32+),
I tend to agree.  Thanks to macros, maintaining source code is not that
hard.  If we ever reach the sanity limit, we may rearrange the source
again.

> the slight modification that the templates be loaded into 
> the init segment, so that the memory consumed can be
> reclaimed at run time.  That would eliminate the only

 That already happens now.  Except from the vmalloc path, which could
likely be handled this way as well, by copying the appropriate handler
to KSEG0 somewhere above standard exception vectors.  That would have the
micro-optimization advantage, we could use the "b" instruction, instead of
the much longer "dla/jr" pair.  Still possibly we can have a single
vmalloc handler only as the epilogue should be the same as for the user
path -- we need have to find a way to hook a jump back somehow in this
case.

> argument I can see against having a larger set of 
> statically-built optimized handlers.  The current
> selection process is ad-hoc based on CPU ID.
> We could easily formalize that a bit, and even

 Well, the current approach seems appropriate.  Only a comment here and
there might be useful, to explain why a particular handler is used (with
an erratum text included if applicable).

> provide a boot command line option to override
> the automatic selection with something "safer".

 Hmm, I think that's an overkill, although for debugging purposes, a
single extremely conservative handler (possibly with some status output to
the log) might be selectable as an alternative.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

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