NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/sys/isis/361

Internet Message Format | 1993-01-05 | 3.5 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!cs.ucf.edu!tarpit!ge-dab!newshost.atl.ge.com!newshost!gthaker
From: [e-mail] (Gautam H. Thaker)
Newsgroups: comp.sys.isis
Subject: Re: Question I got about use of shared memory in Isis
Date: 4 Jan 93 13:28:24
Organization: GE Advanced Technology Laboratories
Lines: 58
Distribution: world
Message-ID: <[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: trantor.atl.ge.com
In-reply-to: [e-mail]'s message of 3 Jan 93 15:23:04 GMT

In article <[e-mail]> [e-mail] (Ken Birman) writes:

   > From: [e-mail] (Ajay Kumar)
   > Subject: RPC on shared memory transport


   >         I've been sampling the discussions on comp.sys.isis
   > for some time. You seem to have done studies of RPCs and
   > various transport mechanisms. Do you know of any implementation
   > of RPCs that uses shared memory as the transport mechanism ?
   > How does the performance of shared memory compare with UDP ,
   > which on a single machine is reliable ? It seems to me that as
   > we get more boxes with multiple CPUs and shared memory on desktops,
   > communicating between different processes on the same machine will
   > become as important as between processes on remote machines . Does
   > isis address these types of architectures in particular ?

   Mach uses this approach to RPC.  Performance is good for big
   messages, but so-so for small ones, since the cost of playing with
   page tables is substantial.  I would email to [e-mail] for
   [....]

Here at GE we are using ISIS on various projects that have  6-10
different types of processes (with 1-3 instances running of each
type) in a given application. We are always concerned about
performance and have had to use SUN OS shared memory between
some pairs of processes in order to meet our goals. The use of
shared memory like this is ok, but I really would rather just
use a single mechanism, namely ISIS messages, for uniformity and
maximum flexibility. If Isis used shared memory we could design
our processes as more or less independent ones and simply co-locate
the heavyly communicating ones on a shared memory MP and everything
would work fine. From Ken's comments it seems that we may see this
for MACH based systems (OSF/1 ?) in the next 6-12 months. Since
Solaris 2.x is also a major commercial system, is any aggressive use
of shared memory by ISIS likely for that OS in the near future?
Is there anything equiv. to MACH IPC on Solaris to let you do this?

   As for Isis, we don't do anything special about this, but in our
   manual, section on "examples", you will find an example of how to
   use shared memory within a group of processes all of whose members
   reside on the same machine.  So, it isn't hard to exploit shared
I need to take another look at this option, but at least some of
our groups members are on different machines.

   The reason I don't do anything specific about this in Isis is that
   management of the memory pool in which messages live is necessarily
   an OS problem -- and Isis is a communication subsystem, not an OS.
yes. BTW, do not see any impact to UI ATLAS arch. due to the
Novell purchase of USL?

   Kenneth P. Birman                              E-mail:  [e-mail]

Gautam H. Thaker ([e-mail]) 609-866-6412 (fax x6397. Dialcom 8-777)
GE Adv. Tech. Lab., MS 145-2; Route 38; Moorestown, NJ 08057.  767-4396 (home)
--
Gautam H. Thaker