Date: Wed, 18 Apr 2001 00:21:36 +0000 (GMT) From: "E.B. Dreger" <eddy+public+spam@noc.everquick.net> To: current@FreeBSD.ORG, smp@FreeBSD.ORG Cc: Alfred Perlstein <bright@wintelcom.net>, Matt Dillon <dillon@earth.backplane.com>, "Justin T. Gibbs" <gibbs@scsiguy.com>, Doug Barton <DougB@DougBarton.net> Subject: SMP architecture (Re: FW: Filesystem gets a huge performance boost) Message-ID: <Pine.LNX.4.20.0104172348410.13343-100000@www.everquick.net> In-Reply-To: <20010417160418.X976@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
(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 <bright@wintelcom.net>
(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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.20.0104172348410.13343-100000>