Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!swrinde!pipex!sunic!trane.uninett.no!eunet.no!nuug!EU.net!uunet!news.delphi.com!usenet From: John Dyson <dysonj@delphi.com> Newsgroups: comp.os.386bsd.bugs Subject: Re: Possible Swapping bug (or design flaw?) Date: Sat, 9 Jul 94 21:05:45 -0500 Organization: Delphi (info@delphi.com email, 800-695-4005 voice) Lines: 25 Message-ID: <hk4RJ35.dysonj@delphi.com> References: <5JUL199421385862@acad3.alaska.edu> NNTP-Posting-Host: bos1g.delphi.com X-To: KIENENBERGER MIKE L <fxmlk@acad3.alaska.edu> KIENENBERGER MIKE L <fxmlk@acad3.alaska.edu> writes: >The problem is that while a "ps aux" shows that the child process has exited >and isn't using any memory, "/usr/sbin/swapinfo -k" shows that the virtual >memory in use was never freed. Additional forks() will use additional virtual >memory until the system finally freezes up when we run out of virtual memory. >Terminating the original process (the parent of each child) finally releases >the swap space allocated and the operating system returns to normal. You are describing a sort-of well known bug in the MACH VM system (at least the way *BSD uses it.) FreeBSD has done significant work to make this problem essentially go-away. The problem has to do with VM objects being left around after a child process exits, etc. It is a difficult problem to solve and the obvious solutions can be *very* inefficient. We have modified the swap pager and written some missing bits in the VM code and all but totally eliminated the problem. There are still some possible second-order problems that we did not solve, but they are very difficult to demonstrate. If any user *ever* demonstrates the problem -- I will be very motivated to fix it (they would be using the system *very* aggressively in *very* special circumstances.) (sorry for so many "verys" :-)). John dyson@implode.root.com