Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!brutus.cs.uiuc.edu!apple!motcsd!hpda!hpwala!hp-and!panek
From: panek@hp-and.HP.COM (Jon Panek)
Newsgroups: comp.arch
Subject: Re: Bus Partitioning?
Message-ID: <6960003@hp-and.HP.COM>
Date: 1 Feb 90 17:57:17 GMT
References: <1990Jan30.174807.14657@ncsuvx.ncsu.edu>
Organization: HP Andover Division (Massachusetts)
Lines: 23

I think there might be an advantage in taking the inherently simpler
approach proposed in the basenote.  So far, most of the responses have
quickly extrapolated to the NxM cross-bar architecture.  While this is
obviously the most general-purpose and most flexible one, it also incurs
the highest implementation cost.

By having a single linear bus with CPUs and Memory distributed along it
in sections which can either be connected to the segments on either side
of it or not, the implementation aspect becomes much more tractable.  One
obvious result of this is that the scheduler must become much smarter;
assigning tightly-coupled tasks to physically proximate CPUs.
 
Rather than having single on/off switches to connect segments of busses,
perhaps a dedicated limited-function CPU could also straddle the boundaries
and serve as a message-transmitter/receiver across otherwise disconnected
segments of the bus.  It would grab bus cycles during dead time of the
main CPUs.  In this way, any CPU could talk with any other CPU, and the
only penalty would be longer latency for physiclly disparate boxes.

Any Master's candidates looking for a research topic???

Jon P
panek@hp-and.HP.COM