[comp.unix.wizards] NOSLEEP in Sys V.3.1 fork.c

rfg@nsc.nsc.com (Ron Guilmette) (08/26/88)

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

jh@pcsbst.UUCP (Johannes Heuft) (08/31/88)

In article <5905@nsc.nsc.com> rfg@nsc.UUCP (Ron Guilmette) writes:
...
>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.
...
>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.
  ...
>Ron Guilmette
>National SemiConductor

I assume that you are elaborating on the AT&T SVR3 distribution for
the 3B2 machines. If you analyse the paging in this distribution
you find that dupreg() finally need contigious physical (!) memory in
order to duplicate the region in question. This seems to be due to the
the MMU architecture of the 3b2 machine. In this case you need NOSLEEP
in order to avoid deadlocks.

On the other hand, if your architecture allows a "copy on write"
strategy (see the ATT SVR2 for VAX) you only need physical memory
for the page table (some deadlock danger here in the SRV2 for VAX!) and
SLEEP could be used. In this case, however, the AT&T paging should be
rewritten completely. - Here I skip some of my opinions concering AT&T
paging.

	Hope this helped
	Johannes Heuft
	unido!pcsbst!jh