Date: Tue, 23 May 2000 10:46:14 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Bruce Evans <bde@zeta.org.au> Cc: Boris Popov <bp@butya.kz>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, "Jordan K. Hubbard" <jkh@zippy.cdrom.com>, current@FreeBSD.ORG Subject: Re: Anyone else seeing jumpy mice? Message-ID: <200005231746.KAA68462@apollo.backplane.com> References: <Pine.BSF.4.21.0005231859060.485-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:The patch seems to have completely broken fast interrupts.
:GET_FAST_INTR_LOCK is neither necessary nor sufficient as far as I can see.
:The necessary and sufficient locking is done by COM_LOCK() in individual
:drivers. The patch changed GET_FAST_INTR_LOCK from s_lock(&fast_intr_lock),
:which does nothing very well, to `sti(); get_mplock(); cli();', which
:essentially de-prioritizes "fast" interrupts from "higher than the highest"
:(higher than clock interrupts which are nominally highest) to "lower than
:the lowest" (lower than all normal interrupts, all software interrupts,
:and all MP-unsafe syscalls).
It isn't quite that bad. Remember that interrupts are vectored to
the cpu already running in supervisor mode, and the MP lock is recursive.
So GET_FAST_INTR_LOCK will generally not block against MP-unsafe
syscalls or anything else. It will still operate as a high-priority
interrupt.
I understand the point about COM_LOCK, and agree - but I also never
trusted the MP-safeness of the fast-interrupt code hack so lets not
commit this until we have a chance to audit the entire fast-interrupt
path. Frankly, I would much rather see MP-safe NIC interrupt code
then MP-safe serial interrupt code.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005231746.KAA68462>