Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!mejac!orchard.la.locus.com!devnet.la.locus.com!richard
From: richard@locus.com (Richard M. Mathews)
Newsgroups: comp.unix.wizards
Subject: Re: Signals and context switches
Message-ID: <1991Jun20.000606.1810264@locus.com>
Date: 20 Jun 91 00:06:06 GMT
References: <1991Jun16.010626.28257@bnlux1.bnl.gov> <1991Jun17.085558.16652@prl.dec.com> <1991Jun17.131027.8700@bnlux1.bnl.gov> <1991Jun18.103934.25635@prl.dec.com>
Organization: Locus Computing Corporation, Los Angeles, California
Lines: 27

This discussion of optimizing context switches reminds me of a problem
encountered in IX/370.  IX/370 (little or no relation to AIX/370) was
an ancient attempt to put Unix on a 370 by having Unix running under
SSS, which in turn may be running on VM.  By the time something like
an interrupt could percolate through all these operating systems, WWIII
could come and go.

Some hacks were put into SSS and IX/370 to get them to work together to
improve performance.  For example, after a fork(), SSS apparently would
be told to immediately run the child.  After an exit(), SSS apparently
would be told to immediately run the parent.  This sped up a benchmark
in which a parent repeatedly does fork()/wait() and each child immediately
exits.  The problem was that nothing else would run.  Simultaneously start
up such a benchmark such that it runs forever and start up a compile of
a standard "hello world" program.  I actually left a machine in such a
state overnight, and the tiny compile never finished.

Moral: be careful about making broad assumptions about optimizations for
your scheduler.

Disclaimer: Opinions are my own, not LCC's or IBM's.  Facts are likely
to be distorted by a brain that long ago turned into tapioca pudding.

Richard M. Mathews			D efend
richard@locus.com			 E stonian-Latvian-Lithuanian
lcc!richard@seas.ucla.edu		  I ndependence
...!{uunet|ucla-se|turnkey}!lcc!richard