On Fri, Apr 11, 2003 at 10:15:06AM +0200, Kevin D. Kissell wrote: > > > > I'm not sure what you mean by TLB translations required for hit > > > > cacheops. If you mean the Index Writeback or Index Invalidate > > > > functions, note that you can (and should) use a kseg0 address to > > > > do this. > > > > Mike was proposing a kseg0 address translating to the right physical > > address, and used with a hit-type cacheop. I believe Ralf (and Linux) > > are just assuming that's no good because it doesn't work if you have > > cacheable memory above 512Mbytes physical address. > > More importantly, it doesn't work in the case of virtually tagged caches, > such as those in the SB-1 and MIPS 20K. On SB1 we just switch to a new ASID which effectivly is a cheap way to invalidate the entire I-cache. Assuming the other process has at most 4k of code resident in the I-cache from it's previous timeslice this even is the optimal solution. But this optimization is a heuristic that hasn't been verified to be optimal for performance. > > I wonder whether anything really bad would happen if you temporarily > > changed the (machine) ASID to that of the address space you wanted to > > invalidate? > > I looked at that when we were investigating the aforementioned > issues with virtually-tagged I-caches. It looked to me as if exceptions > can occur during the invalidation, and that processing those exceptions > can cause signals to be raised to the current process in a manner that > assumes that the TLB and ASID are coherent and in sync with > the scheduler. It may be that just changing the ASID temporarily > would work - most of the time. It may even be that, with a bit > of lashing down of state, disabling of interrupts, setting of flags > to be read by traps.c/signal.c, etc, etc, it could be made bulletproof. > But I don't think that the simple, obvious hack is safe. Yep - it seems like a can of worms sufficiently large to be left closed for 2.4 ... Ralf
