From owner-freebsd-current Wed Apr 18 6:10: 0 2001 Delivered-To: freebsd-current@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id B90A137B42C for ; Wed, 18 Apr 2001 06:09:56 -0700 (PDT) (envelope-from eddy+public+spam@noc.everquick.net) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.10.2/8.10.2) with ESMTP id f3ID9Th19647; Wed, 18 Apr 2001 13:09:29 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Wed, 18 Apr 2001 13:09:29 +0000 (GMT) From: "E.B. Dreger" To: Rik van Riel Cc: Matt Dillon , Alfred Perlstein , Greg Lehey , "Justin T. Gibbs" , Doug Barton , "current @ freebsd . org" Subject: Re: Kernel preemption, yes or no? (was: Filesystem gets a huge performance boost) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Date: Wed, 18 Apr 2001 01:38:14 -0300 (BRST) > From: Rik van Riel > > > 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