Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!usc!rutgers!att!cbnewsh!dwc
From: dwc@cbnewsh.ATT.COM (Malaclypse the Elder)
Newsgroups: comp.unix.i386
Subject: Re: Help!  Altos 5.3.1 fork is failing!
Message-ID: <5050@cbnewsh.ATT.COM>
Date: 25 Oct 89 18:12:11 GMT
References: <506@oglvee.UUCP> <3684@altos86.Altos.COM> <1989Oct25.010725.18353@NCoast.ORG>
Organization: The Legion of Dynamic Discord
Lines: 30

In article <1989Oct25.010725.18353@NCoast.ORG>, allbery@NCoast.ORG (Brandon S. Allbery) writes:
>
> 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.
> 
the people who believe that it is swap space shortage is confusing the
implementation with BSD/SunOS which requires that a page of swap be
allocated with each page that is faulted.  the system v release 3
implementation did not have this restriction.

but the system DOES page whenever freemem drops below the low water mark.
and it swaps when freemem hits zero.  the question is whether the fork
sleeps waiting for the memory.  and as i wrote in an earlier article,
it does not to avoid certain deadlock conditions.

> 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.
> 
for those playing around with paging experiments on release 3, there is
a tunable parameter, maxpmem, which allows one to configure the system
with LESS memory than there actually is.  i think it was put in just for
doing such experiments and never taken out.

danny chen
att!hocus!dwc