From owner-freebsd-current Thu Jun 6 00:20:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA08098 for current-outgoing; Thu, 6 Jun 1996 00:20:17 -0700 (PDT) Received: from bunyip.cc.uq.oz.au (pp@bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA08093 for ; Thu, 6 Jun 1996 00:20:14 -0700 (PDT) Received: from bunyip.cc.uq.oz.au by bunyip.cc.uq.oz.au id <15571-0@bunyip.cc.uq.oz.au>; Thu, 6 Jun 1996 17:19:46 +1000 Received: from orion.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id RAA07140 for ; Thu, 6 Jun 1996 17:20:26 +1000 Received: by orion.devetir.qld.gov.au (8.6.10/DEVETIR-0.3) id QAA14007; Thu, 6 Jun 1996 16:00:53 +1000 Date: Thu, 6 Jun 1996 16:00:53 +1000 From: Stephen McKay Message-Id: <199606060600.QAA14007@orion.devetir.qld.gov.au> To: freebsd-current@freebsd.org cc: syssgm@devetir.qld.gov.au Subject: Re: More on VM, swap leaks X-Newsreader: NN version 6.5.0 #1 (NOV) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Michael L. VanLoon -- HeadCandy.com" wrote: >>Greg Lehey writes: >>>So, here I am, three Emacsen later, all stopped, and I have 5 MB less >>>swap than before. Can anybody else reproduce these results? > >>I decided to test this out. I can start both emacs and xemacs with NO >>failures at all. And not one additional block of swap gets allocated. >>I must in all fairness note that I already had about 16 MB of swap in >>use. >If I'm not mistaken, generally when a process has pages allocated on >swap, those don't ever get removed from swap until the process exits. >So, just because you quit emacs and opened up a big memory hole where >other processes could run again, doesn't mean those other process' >swap pages will get deallocated. >Sure, John may have checked in a swap bug or two >with his recent changes. But the behavior sounds a whole lot more >like standard Unix swap behavior to me. I have to agree with this analysis of the swap behaviour. My under-achieving test box has been compiling for 48 hours now. It has 4Mb ram, 17Mb swap (9Mb used), NFS mounted /usr/src and /usr/obj. It is slow :-) but stable. This is with source dated 1996-06-03 09:15:34, including version 1.98 of pmap.c and version 1.36 of vfs_cluster.c. I do not see any swap loss or ram loss, and any leak must be awfully slow not to have killed it by now. During the previous VM mega-commit (and subsequent instability) I suffered subtly corrupted binaries, and a number of problems went away only when I recompiled everything. I would recommend 'make all install' plus rebuilding emacs. For me, the problems of the current VM mega-commit seem to be over. Until the 1.98 version of pmap.c, my test box would collapse after only a few minutes of compiling. Now it is a powerhouse of snail-speed computing! :-) Stephen.