Date: Wed, 7 May 1997 11:44:42 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: steve@visint.co.uk (Stephen Roome) Cc: terry@lambert.org, freebsd-smp@FreeBSD.ORG Subject: Re: Where to start SMP? Message-ID: <199705071844.LAA21853@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.91.970507182028.6423O-100000@bagpuss.visint.co.uk> from "Stephen Roome" at May 7, 97 06:50:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The point of a GENERIC is to make some that (within memory limits) > > works on as much hardware as possible. The same should be true of > > an SMP-GENERIC, considering it's going to be on a CDROM. > > Okay, that's great but is it feasible to have a GENERIC kernel which > works on both UP and SMP, without losing performance on both > architectures over a different design for each ? No. That's why you buy Oreo's (compile your own kernel) rather than buying generic cookies (run the install kernel). > I don't think so, not without moving to a completely micro-kernel based > approach, but then again, I don't write this stuff, I just use it. > So, as I said earlier, you just need a menu on install that lets you > chose your system stats. Hey, a kernel isn't really very big, you could > actually compile quite a few "GENERIC" kernels for each release. > e.g > GENERIC-UP : single processor freebsd kernel > GENERIC-2SMP : dual processor > GENERIC-4SMP : 4 processor > GENERIC-PCISA : PCI/ISA machine > GENERIC-VLB : vesa local bus machine > GENERIC-SLIM: cut down minimal boot kernel > GENERIC-MOST: bloated near LINT system > > In fact having the option of about 10 different kernels to install at > startup would be a nice idea anyway, it's not necessary, but for those > folks who have problems with having to make boot disks for specific > hardware it might sort that out. It's evil. It's evil because you move the burden of knowledge either to the user or to the install system. Either one just means that you are pushing work into someone else's "in" box. If the user's "in" box, then you are multiplying the work by the number of users. 8-(. This is a bit off topic anyway. We are discussing issues of: GENERIC-SMP : dual processor GENERIC-SMP-BROKEN-MPTABLE : dual processor ... Not issues of SMP vs. UP, so your table above is, at best, incomplete. The 2 vs. 4 is autodetectable, so it's a non-issue in a release system. > 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. 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. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705071844.LAA21853>