Date: Tue, 17 Apr 2001 21:20:45 -0400 From: Bosko Milekic <bmilekic@technokratis.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: Greg Lehey <grog@lemis.com>, Alfred Perlstein <bright@wintelcom.net>, "Justin T. Gibbs" <gibbs@scsiguy.com>, Doug Barton <DougB@DougBarton.net>, "current @ freebsd . org" <current@FreeBSD.ORG> Subject: Re: Kernel preemption, yes or no? (was: Filesystem gets a huge performance boost) Message-ID: <20010417212045.B14803@technokratis.com> In-Reply-To: <200104180047.f3I0lN615938@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Apr 17, 2001 at 05:47:23PM -0700 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010417212045.B14803>