From owner-freebsd-smp Tue Apr 17 17:21:52 2001 Delivered-To: freebsd-smp@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id 3281637B42C; Tue, 17 Apr 2001 17:21:41 -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 f3I0Las13653; Wed, 18 Apr 2001 00:21:36 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Wed, 18 Apr 2001 00:21:36 +0000 (GMT) From: "E.B. Dreger" To: current@FreeBSD.ORG, smp@FreeBSD.ORG Cc: Alfred Perlstein , Matt Dillon , "Justin T. Gibbs" , Doug Barton Subject: SMP architecture (Re: FW: Filesystem gets a huge performance boost) In-Reply-To: <20010417160418.X976@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org (cross-posting to SMP and renaming in an effort to move the thread) > Date: Tue, 17 Apr 2001 16:04:18 -0700 > From: Alfred Perlstein (Repeat disclaimer: I am not a kernel hacker.) > seriously, it would be _trivial_ to: > > 1) make interrupts the only thing that could switch, or > 2) turn interrupt related locks into spinlocks that do the equivelant > of splhigh on that cpu. I just don't like the idea of preempting interrupts. > any further discussion of the underlying implementation is a waste of > time and I refuse to do it any further. No, it's not. We all want greater meaningful concurrency. (i.e., having one CPU do something productive while seven spin or fight over a mutex is pointless.) The underlying implementation is of utmost importance, because we don't want to have a 500% increase in overhead for a 5% increase in concurrency. Sort of like trying to have a 486-based router compressing T3 traffic... [ snip bit about dislike of asleep()/await() ] Okay. Let me rephrase. I meant in a manner similar to asleep()/await(), not necessarily those specific calls. I was thinking about passing a token. Imagine this for a central CPU loop: do { if (cpu_with_token == this_cpu) { whatever_needs_big_lock(); pass_token_to_next_cpu(); } standard_scheduler(); } Cooperatively share a token, as opposed to spinning/sleeping for a mutex. Interrupt handlers are inherently unsafe, because we may or may not have the token. Fine, most handlers are for I/O anyhow; pull/push data to/from a buffer, then go back to the main loop. The portion of the "interrupt handler" that requires the big lock can wait until the proper CPU has the token... it's better than spinning or blocking other CPUs, right? Am I missing something? ("What am I missing?", maybe?) Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet / EternalCommerce Division Phone: (316) 794-8922 --------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message