Xref: utzoo comp.unix.i386:928 comp.unix.wizards:18906
Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!dogie.macc.wisc.edu!uwvax!umn-d-ub!umn-cs!nic.MR.NET!hal!ncoast!allbery
From: allbery@NCoast.ORG (Brandon S. Allbery)
Newsgroups: comp.unix.i386,comp.unix.wizards
Subject: Re: Help!  Altos 5.3.1 fork is failing!
Message-ID: <1989Oct25.010725.18353@NCoast.ORG>
Date: 25 Oct 89 01:07:25 GMT
References: <506@oglvee.UUCP> <3684@altos86.Altos.COM> <9556@june.cs.washington.edu>
Reply-To: allbery@ncoast.ORG (Brandon S. Allbery)
Followup-To: comp.unix.i386
Organization: North Coast Public Access UN*X, Cleveland, OH
Lines: 44

As quoted from <9556@june.cs.washington.edu> by ka@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@NCoast.ORG
uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp
161-7070 (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie), comp-sources-misc@backbone
[comp.sources.misc-related mail should go ONLY to comp-sources-misc@<backbone>]
*Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)*