Subject: Re: Multiprocessor with NetBSD ?
To: mike stone <email@example.com>
From: Greywolf <firstname.lastname@example.org>
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
...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 <email@example.com>
# To: NetBSD-current Discussion List <firstname.lastname@example.org>
# 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.
NetBSD: true inheritors of the UNIX(tm) legacy.