On Mon, 26 Aug 2002, Ralf Baechle wrote: > > Similarly to the refill handlers, the R4k (VCEI/VCED) general exception > > handler no longer fits in 128 bytes. I decided the simplest effective > > solution is to remove the special case and use only a single generic > > handler and only install pointers for VCEI and VCED in the exception > > vector table. Here is a patch. [...] > This is wrong. While handling a VCE exception the caches are in an > inconsistent state and you may not do any load or store operation. Also Hmm, why should this ever be a problem? The vector is only accessed with a single virtual address (KSEG0 or whatever is used for the kernel) so you'll never get another VCED exception for the load while executing the handler. If your concern was true then how could instruction fetching (which is cached) work when handling a VCE exception? Any doc reference? I checked the R4000/R4400 manual thoroughly for any issues with the handlers and none were shown. A kernel is currently running with the patch applied on my R4400SC system and no problems have appeared for about two days. > under some circumstances we handle an enormous number of VCE exceptions > so every cycle shows up in performance. The general exception handler I find VCED load light on my system, but it might not be such for intensive shm operations I suspect, right? The loss is two cycles with the new handler, so I can't really tell if that's worth optimizing... > having outgrown it's 128 bytes was no problem anyway. At 0x80000200 > we have another slot for CPUs that have a dedicated interrupt vector. > The only CPUs with VCE exceptions are the R4000/R4400 SC and MC versions > and none of those has a dedicated interrupt vector so growing into > that slot is no problem at all. Indeed. Well, given the null cost we may go for the two-instruction optimization. But then we have to copy more bytes than we currently do. I'd go for 256 bytes to have a nice, round number. ;-) > Something to doublecheck though - right now we only reserve two instructions > at 0x80000200 and I think that's not enough ... While I haven't seen a problem here, I can't really see any reason for this limitation. I'd go for 128 bytes for consistency. OK, I'll prepare another patch. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
