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