Help! Altos 5.3.1 fork is failing!

[Brandon S. Allbery]

As quoted from <9556 at june.cs.washington.edu> by ka at cs.washington.edu (Kenneth Almquist):
+---------------
| All this assumes that the diagnosis of running out of swap space is
| correct.  I've never used "swap -l", but I've never had any reason to
| doubt the output of sar.  On the other hand, I've never tried to tune
| a release 3.1 system.  If Jim happens to have an unused partition on
| his disk, he could easily see whether adding more swap space makes the
| fork problem go away.
+---------------

It doesn't.  I was running into this on a system rented to a client; I doubled
the swap space, but nothing changed.  (Yes, this is the system with 25776
blocks of swap... after the addition.  It was the first time I encountered
this problem.  I have since seen it on three other systems, one of which is
not currently expandable with more RAM (Series 2000; this is changing, but the
client in question cannot presently take advantage of it).)

I still question the diagnosis, and continue to suspect that Altos 5.3.1 does
not page when it needs space for a page table during a fork(), even when it
can do so.

It should be noted that I patched a Series 600 (the 1000's little brother)
Unix kernel as suggested earlier (although the flag was the reverse of that
specified; did the poster get it backwards or did Altos already do this?) and
am currently running tests on it.  Unfortunately, hitting the trigger point on
a 2MB system is a bit tricky, so I haven't yet reproduced the core memory
conditions which trigger the failure.

One more comment:  I have observed this on systems which are relatively
unloaded, which don't complain when much more heavily loaded.  Specifically, a
few occurrences on our office system, which is usually kept busy by two people
with a full complement of MultiView windows and a minimum of two sessions not
running under MultiView.  I have gotten "fork fail" when not at the full
complement of windows *if* the users start up processes in a particular order,
again arguing for an out-of-*core*-memory condition causing the problem rather
than an out-of-swap condition.

++Brandon
-- 
Brandon S. Allbery, moderator of comp.sources.misc	     allbery at NCoast.ORG
uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery at hal.cwru.edu bsa at telotech.uucp
161-7070 (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie), comp-sources-misc at backbone
[comp.sources.misc-related mail should go ONLY to comp-sources-misc@<backbone>]
*Third party vote-collection service: send mail to allbery at uunet.uu.net (ONLY)*