Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!uniwa!cujo!cc.curtin.edu.au!zrepachol From: zrepachol@cc.curtin.edu.au (Paul Repacholi) Subject: Re: PROJECT IDEA: Symmetric Multi-Processing (SMP) for 386BSD? Message-ID: <1992Jun29.002600.1@cc.curtin.edu.au> Lines: 40 Sender: news@cujo.curtin.edu.au (News Manager) Organization: Curtin University of Technology References: <1992Jun25.070736.6370@iitmax.iit.edu> <l4jcegINNs1k@neuro.usc.edu> <1992Jun26.013019.23629@gateway.novell.com> Date: Sun, 28 Jun 1992 15:26:00 GMT In article <1992Jun26.013019.23629@gateway.novell.com>, terry@npd.Novell.COM (Terry Lambert) writes: > 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 This is not a SMP system as the term is commonly used nowdays. It is a global memory design a la 11/74, C.mmp and others. Amongst other things it requires that all I/O structures have extentions to show the conectivity of the hardware. Some form of inter-processor interupt, a halt/start and reset access from other processors is also needed. RSX-11M-PLUS is a very clean implement- ation ( except for SAVE and the boot hair ) of one of these systems and is IMHO well worth studing. After you have got your kernal and IO system happy, you still have to spec and implement extentions to your system interface and user level functions. EG shared Writable sections now can have different semantics if not used with concurrent MP access in mind. Do you wish to bind certain processes to a subset of CPUs? How do you start/stop CPUs? > 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. > The PC bus is a major impediment to ANY serious computing. Getting reliability into a system with a PC bus would be a huge job. The only way I could see to do it would be to have a bus adapter between the PC bus and everything else. This is in addition to the 'usual' problems of cache coherence ect... ~Paul