Date: Wed, 18 Apr 2001 13:09:29 +0000 (GMT) From: "E.B. Dreger" <eddy+public+spam@noc.everquick.net> To: Rik van Riel <riel@conectiva.com.br> Cc: Matt Dillon <dillon@earth.backplane.com>, Alfred Perlstein <bright@wintelcom.net>, Greg Lehey <grog@lemis.com>, "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: <Pine.LNX.4.20.0104181234330.19344-100000@www.everquick.net> In-Reply-To: <Pine.LNX.4.21.0104180136190.14442-100000@imladris.rielhome.conectiva>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Wed, 18 Apr 2001 01:38:14 -0300 (BRST) > From: Rik van Riel <riel@conectiva.com.br> > > > Hence, my philosophy is that task switching and preemption are > > necessary evils because hardware does not perfectly accomodate > > software. If we must, we must... otherwise, use co-op switching as > > the next best thing to straight run-to-completion. > > Except that for the [extremely performance critical] interrupt > handlers the "software" is under control of the folks who write > the OS. > > You need preemption for userspace because it's possibly "hostile" > software, but things like the interrupt handlers and the kernel > code are under your control ... this means you can code it to be > as efficient as possible without impacting latency too much. Right. This is why I think that messing with pre-emption inside interrupt handlers is a bad thing. If kernel code doesn't cooperatively time-share, then we likely have bigger problems than task switching. :-) Hence I'm curious about replacing Giant with a token-passing mechanism. If the token equals your CPU number, you have "Giant"... do what's needed. Then set the token to the next CPU, and do what doesn't require "Giant". Matt pointed out (to me off-list IIRC) that the mutex usually shouldn't have to spin. However, passing a token would involve changing the value of some known memory location... that should be even faster and simpler than a mutex. No bus locking, no spinning... AFAIK, there isn't any "good" support specifically for token passing. But memory reads and writes that don't even require the lock prefix... how much faster and simpler can you get? Want finer-grained control than "Giant"? Any time you have "Giant"/token, you can poll (and claim, if available) any more-specific mutex. Nobody else has G/tk, so there would be no races. By using fine-grained co-op mutexes, there is very little that must be done when we have G/tk, thus minimizing wait for G/tk. Note, too, that we run our standard scheduler when we don't yet have G/tk, so we're not even blocking unless the CPU is totally idle... and then, the degenerate case is spinning. Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet / EternalCommerce Division Phone: (316) 794-8922 --------------------------------------------------------------------------- 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?Pine.LNX.4.20.0104181234330.19344-100000>