On Mon, Aug 05, 2002 at 06:59:58PM -0400, Greg A. Woods wrote:
> Today I managed to get around to compiling a kernel with Manuel's patch.
> 
> My formerly speedy SS-1+ is now crawling like a snail, even just running
> as a diskless workstation!  :-)

Yes, these cache flush ops have a high cost.

> [...]
> What's interesting about this change is that if indeed it fixes the
> problem there's some indication that the failure is perhaps not a 100%
> certain condition, but rather still highly timing dependent.  I wonder
> how often the offending block of code is encountered vs. how often
> me_alloc() is called.  It would seem from the profiling results that
> it's almost 1:1, at least it seems so for each process context switch.
> 
> Also interesting is that if there's some critical timing issue with
> cache_flush_segment() then what about the other invocations?  Are they
> similarly vulnerable too?  What could this problem be?

Well, I tried different things to narrow down the code path which triggers the
problem, and it's really cache_flush_segment() called from me_alloc()
(maybe it's just because it's a code path used very often, though).

> 
> Are other sun4c users really avoiding newer NetBSD?  Is that why so few
> people have encountered this problem?

It's possible. Remember that this only occurs on older sun4c (the ones
with "sw flush cache"). IPX and SS2 are fine.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--