Date: Fri, 29 Aug 1997 13:33:21 -0600 From: Steve Passe <smp@csn.net> To: smp@freebsd.org Subject: HEADS UP: new INTerrupt algorithms Message-ID: <199708291933.NAA08591@Ilsa.StevesCafe.com>
next in thread | raw e-mail | index | archive | help
Hi,
I just committed 2 new algorithmic changes affecting the handling of
FAST_INTR()s:
Modified files:
sys/i386/include smptests.h
sys/i386/i386 exception.s mplock.s simplelock.s
sys/i386/isa apic_ipl.s apic_vector.s intr_machdep.c
intr_machdep.h ipl.s ipl_funcs.c
1: There was a small window during the MP-safe spl function locking
where an INT would be steered to a CPU NOT holding the giant lock.
This caused sever silo overflow problems on systems doing heavy
serial IO.
The Task Priority Register value is now raised while spinning
on the giant lock to a value higher than that used while spinning
on simple locks, eliminating most cases of this problem.
Thanx to Dave Adkins for debugging and testing this code.
2: I reworked the priority levels used for FAST_INTR()s to be above
those used for all regular (ie INTR()) interrupts. I also changed
the mplock code to allow acceptance of FAST_INTR()s while blocking
acceptance of INTR()s durint the period that a caller of mplock
is spinning on the giant lock. This means that 1 CPU can be inside
the kernel for either a syscall or regular INTR() ISR while another
CPU can be inside handling an FAST_INTR().
Note that change #2 makes change #1 irrelevant for FAST_INTR()s, but still
affects steering of regular INTR()s. Change #1 is built-in. Change
#2 is controlled by smptests.h: FAST_HI, and is on by default. You
should cvsup the lasest files and use as is. If you have deadlock
problens you can turn off FAST_HI to fall back to #1 for both INT types.
I would like feedback as to how these changes affect the silo overflow problem
and sio responsiveness.
--
Steve Passe | powered by
smp@csn.net | Symmetric MultiProcessor FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708291933.NAA08591>