Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!ginosko!brutus.cs.uiuc.edu!apple!altos!altos86!jerry
From: jerry@altos86.Altos.COM (Jerry Gardner)
Newsgroups: comp.unix.i386
Subject: Re: Help!  Altos 5.3.1 fork is failing!
Message-ID: <3696@altos86.Altos.COM>
Date: 23 Oct 89 23:49:02 GMT
References: <506@oglvee.UUCP> <1989Oct20.020309.2081@NCoast.ORG>
Reply-To: jerry@altos86.UUCP (Jerry Gardner)
Organization: Altos Computer Systems, San Jose, CA
Lines: 33

In article <1989Oct20.020309.2081@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery) writes:
>
>As far as I can tell, "fork failed"s happen when memory is mostly full and
>something wants to fork and for some stupid reason Altos 5.3[a-d][DT][0-9]
>doesn't want to page anything out to make more room in core even though it can
>do so.  I have some "sar" output that corroborates this, "fork failed" happens
>when a process tries to fork and there are < 100 free 512-byte (I think that's
>the units sar uses, I need to check) chunks of memory.
>
>I plan to ram this down Altos T/S's collective throat, since they haven't
>fixed it in 5.3dT1 and I reported it in 5.3bT1 (3 upgrades have gone by so
>far...).
>

The fork() failures you are seeing are occuring when procdup() calls
dupreg().  Dupreg() calls ptsalloc() which eventually calls getcpages() to
allocate memory for page tables to map the new child process' u-area.  
Apparently, the kernel is paranoid in one place here and it calls ptsalloc
with a flag that doesn't allow it to sleep.

The best way to make this problem go away is to get more RAM.  You'd be
amazed how little paging a 64MB 2000 will do.






-- 
Jerry Gardner, NJ6A					Altos Computer Systems
UUCP: {sun|pyramid|sco|amdahl|uunet}!altos86!jerry	2641 Orchard Parkway
Internet: jerry@altos.com				San Jose, CA  95134
I survived the Big One, October 17, 1989                946-6700