Help! Altos 5.3.1 fork is failing!
Brandon S. Allbery
allbery at NCoast.ORG
Wed Oct 25 11:07:25 AEST 1989
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 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)*
More information about the Comp.unix.i386