From owner-freebsd-smp Thu May 8 05:54:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA25092 for smp-outgoing; Thu, 8 May 1997 05:54:21 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA25087 for ; Thu, 8 May 1997 05:54:18 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by bagpuss.visint.co.uk (8.7.5/8.7.3) with SMTP id OAA23623; Thu, 8 May 1997 14:04:58 +0100 (BST) Date: Thu, 8 May 1997 14:04:57 +0100 (BST) From: Stephen Roome To: Terry Lambert cc: freebsd-smp@FreeBSD.ORG Subject: Re: Where to start SMP? In-Reply-To: <199705071844.LAA21853@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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