Subject: Re: Multiprocessor with NetBSD ?
To: mike stone <>
From: Greywolf <>
List: current-users
Date: 06/06/2001 12:35:09
And what's wrong with delivering pizzas in a Formula 1 racer?

"Guaranteed to deliver in 3 minutes or less (modulo the time it takes to
 actually make and bake the pizza)." :-D

But point taken.

With 4 or more processors, though, you can probably run AP on two of them
(have one bound to handling I/O, one handling something else) and SMP
on the other two or more.  Technically, I suppose that's an AP system, but
it would certainly blur the lines.

Would it make sense to build along AP lines, or would that be way too
much of a loss?  My thinking was if it wasn't a horrible hit, you might
be able to build a kernel for AP for one workload and build SMP for the
other one...

...or Did I Miss Something Here[TM]?


On Wed, 6 Jun 2001, mike stone wrote:

# Date: Wed, 6 Jun 2001 14:24:20 -0500
# From: mike stone <>
# To: NetBSD-current Discussion List <>
# Subject: Re: Multiprocessor with NetBSD ?
# > That's what some literature calls an "Associated Processor"
# > configuration, in direct contrast to a "Symmetric MultiProcessor",
# > and indeed in contrast to a multiprocessor (homogeneous or
# > heterogeneous) in which there's one or more main processor as well
# > as one or more specialised I/O processors.
# that sounds familiar, and i'm happy to accept those definitions.
# i also concede that under those definitions, i was using the term
# 'SMP' incorrectly.
# my last post was a weak attempt to compare the relative merits of
# AP -v- SMP.   while SMP does have its strengths, it also has weaknesses.
# and like any technology, SMP is best suited to a particular problem set.
# AP also has strengths and weaknesses, and a range of problems for which
# it happens to be useful.
# my question is "how well does SMP support the work we're most likely
# to do?" with the corrolary, "would AP provide equal, better, or worse
# support for that same work?"
# to me, it seems that people associate "multiple CPUs" with "SMP"
# somewhat arbitrarily, but please allow me to insert massive
# disclaimers at this point, as i do *not* want to shit on the shoes
# of the NetBSD developers currently working on SMP code.   that would
# be snotty, stupid, and rude.   mad props, guys.. you know far more
# about the kernel than i do, which, in the meritocracy of hackerdom,
# pretty much says it all.   i'm thinking of tech journalists, Linux
# kiddies on Slashdot, and other creatures that might one day evolve
# into single-celled organisms.. the hordes who drag code into being,
# and keep bad ideas on life-support forever, with the sheer force
# of their ceaseless yammering.
# my concern is that SMP may be equivalent to building a really great
# formula-one racecar that will be used mostly for delivering pizzas or
# plowing fields.   i'd be happy to hear anyone's reasons for thinking
# that SMP *is* the best route to go, because i'm not on an anti-SMP
# crusade.   i'd just like to feel comfortable thinking that NetBSD
# provides a workable solution for the right problem, rather than an
# elegant solution for the wrong problem.
# > BTW, according to Blaauw & Brooks it is _incorrect_ to refer to the
# > processor contention in accessing shared memory as the "von Neumann
# > bottleneck."
# works for me.   memory contention is a serialization issue, and thus
# falls under Amdahl's Law.   i apologize for running the two ideas
# together, if i did.   my original point.. from which i admit i've
# drifted.. was that adding CPUs doesn't give linear speedup.   the
# rest has been (largely) personal prejudice piped through /dev/soapbox.
# ;-)
# mike
# .

NetBSD: true inheritors of the UNIX(tm) legacy.