Date: Sun, 20 Apr 1997 15:21:59 -0700 (PDT) From: Steve Passe <fsmp> To: freebsd-smp Subject: cvs commit: sys/i386/i386 mpapic.c sys/i386/include mpapic.h Message-ID: <199704202221.PAA21068@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
fsmp 97/04/20 15:21:58 Modified: i386/include mpapic.h i386/i386 mpapic.c Log: changed default behaviour from FAST_IPI to FAST_IPI_NOT. added default #define for APICIPI_BANDAID. The purpose of these changes is to create a short-term fix for the APIC_IO freeze problem. Undefining FAST_IPI changes the calls from inlines to real functions, only real effect should be speed, and I can't see any measurable difference so far. APICIPI_BANDAID invokes a "lazy delivery" mode for IPIs where we bail out after an arbitrary period, assumming we are in the "dead-lock" condition, but that the IPI will eventually get delivered. The early exit should allow the mplock to be freed, and the dead-lock to be avoided. IF it still hasn't been delivered by the next call to apicIPI (and after waiting a LONG time in this next call) we finally panic. This new method may add some SLIGHT statistical chance of corrupted memory, as we don't wait for the SMP_INVLTBL IPI to definately reach the target CPU, but since the current model already has that failing (it's NOT sync'ed with the target CPU(s)) I *think* its better than not using it. And it should be much better than the possible disk corruption fron hitting big red to unfreeze the system. To revert to the old behaviour change i386/include/mpapic.h from: #define FAST_IPI_NOT #define APICIPI_BANDAID to: #define FAST_IPI #define APICIPI_BANDAID_NOT Revision Changes Path 1.11 +3 -2 sys/i386/include/mpapic.h 1.27 +37 -1 sys/i386/i386/mpapic.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704202221.PAA21068>