Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 8 May 1997 14:04:57 +0100 (BST)
From:      Stephen Roome <steve@visint.co.uk>
To:        Terry Lambert <terry@lambert.org>
Cc:        freebsd-smp@FreeBSD.ORG
Subject:   Re: Where to start SMP?
Message-ID:  <Pine.BSF.3.91.970508134648.21666E-100000@bagpuss.visint.co.uk>
In-Reply-To: <199705071844.LAA21853@phaeton.artisoft.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 7 May 1997, Terry Lambert wrote:
            		[BIG snip]
> Stephen Roome wrote: 
> > Of course, I would think that SMP support should remain as a compile time 
> > option rather than run-time. Unless UP is as a poor-mans SMP, but that 
> > would slow the system on a UP arch. SMP isn't much different from UP from 
> > the user point of view (in fact how many -users- know/care how many 
> > processors they have). It's only in the installation that problems occur, 
> > so the handholding as far as SMP goes will always be a problem until UP 
> > becomes just a 1 processor SMP solution.
> 
> There is little architectural difference between supporting SMP and
> supporting general kernel preemption necessary for kernel multithreading
> or Real Time scheduling in the UP case.  The difference is in mutexes vs.
> semaphores, for most things, so that the synchronization occurs across
> processor memory domains instead of in a single memory domain.
>
> The UnixWare 2.x kernel's UFS performed 160% of UnixWare 1.x's UFS
> on the same UP hardware because of concurrency wins that came with
> SMP-ising the kernel, even without the lock strategy switching. 

> So do I think UP will be better off with an SMP kernel?  Yes, if it's
> done correctly.

Well, this was my point, the question then is, are there people out there 
smart enough to actually write the bits of necessary evil self-modyfying 
code to get something like this done so that UP and SMP are the same 
kernel with run time options. Without it actually taking 100 times longer 
and not actually being a 100* improvement. I doubt it, especially after 
your next para.

Personally, I think that it would be an amazing claim to have a GENERIC 
kernel that could run on both UP and SMP, and utilise each hardware.

> Now as to UP vs. SMP locking: that's an isolated enough issue that
> David Miller's point about self-modifying code is a good point.  But
> it would mean isolating all code up to the point of the SMP startup
> in such a way as to either not encounter locking primitivs, or, more
> likely, not encounter the hot-patch code in the boot phase, defaulting
> to one or the other, and then replacing the function pointer at the
> call address with the hot patch function.  A lot of voodoo.

A lot of headaches. It'd be great fun debugging!

--
Steve Roome
Technical Systems Manager, Vision Interactive Ltd.
E: steve@visint.co.uk      M: +44 (0) 976 241 342
T: +44 (0) 117 973 0597    F: +44 (0) 117 923 8522




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.970508134648.21666E-100000>