Path: utzoo!attcan!uunet!lll-winken!lll-tis!mordor!joyce!ames!amdahl!nsc!rfg
From: rfg@nsc.nsc.com (Ron Guilmette)
Newsgroups: comp.unix.wizards
Subject: NOSLEEP in Sys V.3.1 fork.c
Message-ID: <5905@nsc.nsc.com>
Date: 25 Aug 88 19:05:20 GMT
Reply-To: rfg@nsc.UUCP (Ron Guilmette)
Organization: National Semiconductor, Sunnyvale
Lines: 32


Are there any System V.3.1 kernel hackers out there who can answer this
question about the V.3.1 fork() implementation?

I noticed that on one system we have configured with 4 MB of memory (small by
our current standards), I was often getting "no more processes" whenever there
was somebody else on the system doing something which used up most of the
available real memory.  (The kernel itself uses a big chunk of course).

I investigated and found out that the System V.3.1 "fork.c" makes a call to
dupreg() (duplicate region) to create the child process, but it passes in the
NOSLEEP parameter so that it will NEVER WAIT for other processes to swap out.
Instead the fork just fails, returning -1!  Note that the BSD 4.3 fork() is
very different and it seems to be willing to wait for space to become available
via swaping.

I though that V.3.1 code was pretty stupid so I removed the NOSLEEP and now I
can get many more processes with the same memory configuration.  Unfortunately,
when I now run my "fork_limit" test program (which just forks as many children
as it can) the system will eventually slow down untill it is useless and has
to be rebooted.

I'd like to know if other people have seen and/or solved these problems.

Ron Guilmette
National SemiConductor
Internet: rfg@nsc.nsc.com   or   amdahl!nsc!rfg@ames.arc.nasa.gov
Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfg
-- 
Ron Guilmette
National SemiConductor
Internet: rfg@nsc.nsc.com   or   amdahl!nsc!rfg@ames.arc.nasa.gov
Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfg