Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!samsung!sdd.hp.com!mips!newsun!gateway.novell.com!terry From: terry@npd.Novell.COM (Terry Lambert) Newsgroups: comp.unix.bsd Subject: Re: PROJECT IDEA: Symmetric Multi-Processing (SMP) for 386BSD? Message-ID: <1992Jun26.013019.23629@gateway.novell.com> Date: 26 Jun 92 01:30:19 GMT References: <1992Jun25.070736.6370@iitmax.iit.edu> <l4jcegINNs1k@neuro.usc.edu> Sender: news@gateway.novell.com (NetNews) Organization: Novell NPD -- Sandy, UT Lines: 62 Nntp-Posting-Host: thisbe.eng.sandy.novell.com In article <l4jcegINNs1k@neuro.usc.edu> merlin@neuro.usc.edu (merlin) writes: >Is anyone working on a freely redistributable Symmetric >Multi-Processing (SMP) option for use with the free BSD >'386/'486 UNIX system? The concept here would be to do >some work on developing software to go with an extremely >low cost shared memory system interfaced to existing low >cost processor boards via ribbon cables to the existing >SIMM sockets. The goal would be to produce a very cheap >desktop supercomputing system (perhaps 10 '486 boards) >for use in large scale simulation and analysis projects. > >What is involved in completing this kind of SMP option? Offhand, I'd have to say that ribbon cables and such are pretty much out of it. There are really two options: 1) Some other board, built for SMP. This requires a lot more than you'd expect in the way contention resoloution and shared memory access, and cache updating rather than cache invalidation is really the way to go. This pretty much means "new computer". 2) Use Transputer (or other meant-to-be-multiprocessor-in-a-DOS-box-slot) computer (ie: Intel Inboard is out). There are a couple of these that SCO has been promising to support for years. The first option would require considerable work (although a friend of mine is in the process of doing an SMP hardware design using MIPS R4000's, as I write this), and the second is pretty unreasonable, given past perforamce in this area by PC boards which were supposed to do this. Even if you went to a top-of-the-board interconnect to avoid having to talk between boards on the slow EISA/ISA bus, you still have the problem of talker-negotiation. This is usually handled by a single bus processor, or a complex bus-grant scheme, which isn't very scalable. After the hardware problems are resolved, you will still need to rewrite a large portion of the kernel code for multiprocessing; the signal and VFS subsystems would be a problem on their own without touching the need for multiple requisite destination for interrupts within the device drivers (how do you make an "unbusy" processor handle the ISR rather than a "busy" one?). This is probably pretty much insoluable unless you throw out the PC bus altogether, except as a power source and I/O processor. I will be giving some time to help port BSD 4.4 to my friends box, once it's complete, but I`d hesitate trying to tackle SMP machine design within the constraints of the PC bus unless there were some serious money involved; CSRG is having a hard enough time with a PD software-only project... can you imagine the hassle involved in a combined hardware/software project such as you suggest? I don't think you are likely to see a non-commercial SMP box anywhere in the near future until someone comes out with SMP chip sets. My two cent's worth, Terry Lambert terry_lambert@gateway.novell.com terry@icarus.weber.edu --- Disclaimer: Any opinions in this posting are my own and not those of my present or previous employers.