On Tue, 20 Aug 2002, Maciej W. Rozycki wrote:
> > Please accept the patch (from my previous mail). I'm using it now for
> > two days, and I've got one mail telling me that it works for its sender.
>
> Ugh, this should be a separate set of functions selected at the run time.
> It should be fairly trivial to rewrite it this way (best done with
> processor-specific functions expanded from common templates for ease of
> maintenance), but the size of the resulting interrupt masking window is
> unacceptable. A more finegrained implementation is really desireable,
> with an interrupt enable window every page or so, but your proposal should
> be fair enough for the sake of usability once rewritten as I suggested.
An additional thought that just came to my mind: it might be possible to
avoid masking interrupts with a dummy ll/sc pair only checking if an
interrupt happened within the critical code. It should be easy to
validate since only a single mask of a processor would make use of the
code. The real question is: "Do the affected cache operations corrupt any
state or do they only work on wrong lines?" If the latter, the approach
should work for all operations except from "Hit_Invalidate_D" that
corrupts state by definition (but it isn't used by any R4k processor, so
it may simply be replaced with a panic()). Unfortunately, the knowledge
does no longer exist within IDT, but maybe someone else knows?
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
|