From owner-freebsd-current Tue Apr 17 18:19:44 2001 Delivered-To: freebsd-current@freebsd.org Received: from technokratis.com (modemcable092.3-201-24.mtl.mc.videotron.ca [24.201.3.92]) by hub.freebsd.org (Postfix) with ESMTP id BC1A437B446 for ; Tue, 17 Apr 2001 18:19:39 -0700 (PDT) (envelope-from bmilekic@technokratis.com) Received: (from bmilekic@localhost) by technokratis.com (8.11.3/8.11.3) id f3I1Kk214991; Tue, 17 Apr 2001 21:20:46 -0400 (EDT) (envelope-from bmilekic) Date: Tue, 17 Apr 2001 21:20:45 -0400 From: Bosko Milekic To: Matt Dillon Cc: Greg Lehey , Alfred Perlstein , "Justin T. Gibbs" , Doug Barton , "current @ freebsd . org" Subject: Re: Kernel preemption, yes or no? (was: Filesystem gets a huge performance boost) Message-ID: <20010417212045.B14803@technokratis.com> References: <200104160259.f3G2xqs06321@aslan.scsiguy.com> <200104160616.f3G6GI973782@earth.backplane.com> <20010417011957.W976@fw.wintelcom.net> <20010418093212.A80877@wantadilla.lemis.com> <200104180047.f3I0lN615938@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104180047.f3I0lN615938@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Apr 17, 2001 at 05:47:23PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 17, 2001 at 05:47:23PM -0700, Matt Dillon wrote: > Proposed: > > mainline kernel { > get_spin_mutex(&somemutex); > . > . > masked interrupt occurs, interrupt structure contains array > of mutexes the interrupt will need. Check said mutexes, one > found to be held by current cpu. Set interrupt-pending bit > in mutex and iret immediately. You cannot be pre-empted by an interrupt if you are holding a spin mutex, AFAIK, even under present implementation. > . > . > release_spin_mutex(&somemutex) > (bit found to be set in mutex, triggers interrupt reissuing code) > } > > And there you have it. The mutex/array test is takes very little time > being a read-only test that requires no bus locking, and the collision > case is cheap also because the current cpu already owns the mutex, allowing > us to set the interrupt-pending bit in that mutex without any bus > locking. The check during the release of the mutex is two instructions, > no bus locking required. The whole thing can be implemented without any > additional bus locking and virtually no contention. > > The case could be further optimized by requiring that interrupts only > use a single mutex, period. This would allow the mainline interrupt > routine to obtain the mutex on entry to the interrupt and allow the > reissuing code to reissue the interrupt without freeing the mutex that > caused the reissue, so the mutex is held throughout and then freed by > the interrupt itself. > > Holy shit. I think that's it! I don't think it can get much better then > that. It solves all of BDE's issues, solves the interrupt-as-thread > issue (by not using threads for interrupts at all), and removes a huge > amount of unnecessary complexity from the system. We could even get rid > of the idle processes if we wanted to. What happens if we get an interrupt, we're thinking about servicing it, about to check whether we're already holding a mutex that may potentially be used inside the mainline int routine, and another CPU becomes idle? In this particular case, let's say that we decide that we have to set ipending and iret immediately, because we're already holding a potential lock when we got interrupted. Isn't the result that we have a second CPU idling while we just set ipending? (I could be missing something, really). Also, some mainline interrupt code may need to acquire a really large number of locks, but only in some cases. Let's say we have to first check if we have a free cached buffer sitting somewhere, and if not, malloc() a new one. Well, the malloc() will eventually trigger a chain of mutex lock operations, but only in the case where we lack the cached buffer to allocate it. There is no practical way of telling up front whether or not we'll have to malloc(), so I'm wondering how efficiently we would be able to predict in cases such as these? > -Matt Cheers, -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message