Date: Tue, 16 Jul 1996 09:52:18 +0100 (BST) From: dave edmondson <davided@sco.com> To: Jan-Simon Pendry <jsp@sequent.com> Cc: Michael Hancock <michaelh@cet.co.jp>, Warner Losh <imp@village.org>, Bruce Evans <bde@zeta.org.au>, matt@lkg.dec.com, freebsd-hackers@freebsd.org, tech-kern@netbsd.org Subject: Re: Some interesting papers on BSD ... Message-ID: <199607160852.JAA00542@zero-gravity.netlab.london.sco.com> In-Reply-To: <9004.837340145@lonsqnt.uk.sequent.com> References: <Pine.SV4.3.93.960714174257.1176B-100000@parkplace.cet.co.jp> <9004.837340145@lonsqnt.uk.sequent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jan-Simon Pendry writes: : unless you redesign the interrupt mechanism, you still have to : raise spl levels for locks on data structures that can be accessed : from interrupt handlers (or timeouts etc). if the cpu runs at the : normal spl, it may end up taking an interrupt and then trying to : lock a structure that the interrupted thread on the cpu had already : locked. this is, of course, true. the problem with this approach on many x86 implementations, where raising the spl level means re-programming the pic masks, is that fiddling with the pic is expensive (as bruce mentioned a while ago). now it's happening all the more often, potentially unnecessarily (if you don't take an interrupt in the time that you hold the lock then the pic twiddling was wasted). intel did some interesting work on a soft-spl scheme where the actually pic fiddling was deferred until the interrupt actually arrived. an implementation of this scheme for unixware exists, and can produce performance noticable improvements in many situations. another problem with this, when combined with `time to market' pressures, is that the decisions about what spl level to use with any lock is apparently easy, but often botched. as a hard example, sco's openserver typically raises the spl level to 7 (the highest, which blocks everything) on _all_ lock acquisitions. this causes dire interrupt starvation, and hits 8250 serial stuff like a hammer (ever try getting reasonble serial performance from a dual 486 or pentium system running our mpx 3.0 release ?).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607160852.JAA00542>