Date: Wed, 7 May 1997 18:50:39 +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.970507182028.6423O-100000@bagpuss.visint.co.uk> In-Reply-To: <199705071704.KAA21345@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 7 May 1997, Terry Lambert wrote: > > > The SMP options also need to be runtime instead of compile time > > > configurable, based on flags values which can be modified at boot > > > configuration time. This would let a single SMP kernel work on all > > > hardware, regardless of which options must be twiddled to get it to > > > go. The alternative is multiple "SMP GENERIC" configurations -- not > > > a likely event. > > > > Maybe, but surely some of the changes to run an efficient SMP system > > should come at kernel compile level. Unless FreeBSD moves to a modular > > system on the scale of something like HURD this looks likely to decrease > > performance. > > Depends on whether the options are set with negative or positive > logic, and at what level they are wired in. Best case, they cause > the use of different contents of an existing function pointer and > are set at boot time. Worst case, they are an extra compare and > branch in a path. Is this really feasible in terms of development time. For the best case you're describing isn't it going to take a lot longer to write stuff? If so, wouldn't it be too long? > > If you want optimal performance, then have #ifdef's to dike out the > compares (worst case) at compile time, and then *you* compile your > kernel. > I'd want optimal performance, but imho it's not feasible/possible. Unless of course you go totally microkernel.... <inane rambling section> Although I'm sure enough people will be arguing macro/micro kernel for a few millenia yet I don't think moving FreeBSD towards 1000's of lkm's is going to improve it, but it would/might give a higher degree of platform / architecture support... just think: /lkm/mod_smp.o nasty?! </inane rambling section> > 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 ? 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. > > > > My suggestion was aimed at main-streaming the code so that there would > > > be more feedback, while at the same time offloading some of the issues > > > requring hand-holding to the standard UP kernel channels. > > > > Hand holding gets a user base, don't knock it. It worked for Windows. > > I understand. But if you can automate it to the level that there isn't > a lot of SMP-specific hand-holding, then you've freed up resources to > work on SMP. 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. > Any opinions in this posting are my own and not those of my present > or previous employers. Any opinions in this posting are my own and not those of my present or previous employers, altough it's definitely their fault I'm feeling so damn incoherent at the moment. Steve Roome
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.970507182028.6423O-100000>