Subject: Re: Multiprocessor with NetBSD ?
To: Greywolf <email@example.com>
From: Steven J. Dovich <firstname.lastname@example.org>
Date: 06/06/2001 13:54:43
On Wed, 06 Jun 2001, greywolf wrote:
> 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...
> On Wed, 6 Jun 2001, mike stone wrote:
> # 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?"
A lot of this discussion revolves around the OS software contribution
to an SMP system. There is an underlying prerequisite of hardware
that can support symmetric access. Once you have a hardware system
where any processor can manipulate the devices/system, then SMP is
mostly a matter of not imposing a limitation in the OS implementation.
I will note that for the i386 MP platform standard, I recall seeing
systems where the choice of boot processor is a BIOS setting. Each
processor is equally capable of booting and configuring the system.
SMP-hardware means that there is no underlying reason why the OS
should limit all device access to a subset of the processors. To
do so means that any code running on the restricted access processor
would have additional latency in I/O against those devices (latency
that the hardware architecture does not justify). You might want
to isolate a processor for a special purpose, such as DSP processing
for a WinModem, or dedicated RAID checksumming. But such an isolated
processor would not be a good candidate for running user code for
parallel make. That would result in constant service requests posted
against one of the 1st-class processors to provide the normal system
If the hardware is symmetric, then it seems most reasonable to
fully exploit that symmetry. To suggest that we should not exploit
it needs a better characterization of expected workload, and a
justification of the benefits of ignoring the hardware capabilities.