From owner-freebsd-current Thu May 27 11:15:14 1999 Delivered-To: freebsd-current@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.144.32]) by hub.freebsd.org (Postfix) with ESMTP id AA55615932 for ; Thu, 27 May 1999 11:15:11 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.8.8/8.8.8) with ESMTP id LAA09515; Thu, 27 May 1999 11:15:01 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Date: Thu, 27 May 1999 11:14:59 -0700 (PDT) From: Doug White To: Eric Haug Cc: current@FreeBSD.ORG Subject: Re: process did not exit properly after kill signal In-Reply-To: <199905261203.HAA03513@mnw.eas.slu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 26 May 1999, Eric Haug wrote: > Hi, > I have a pr440fx dual PPro system with 132Mb. > I replaced memory and was testing memory with a short program > (included below) and decided to try to kill it > keyboard signals did change what the system was doing > in that the swapping that was occurring stopped. > kill -9 PID did not have the usual effect. > #define L 32 > > long j[L][1024][1024]; Hm... a long is 4 bytes, right? So if I'm doing my math right, you issued a request for 128MB of RAM with this declaration, then touched each page. This means that the VM system has to allocate space for all that. This is hammering your swap more than your memory. :) The kernel will complete the alloc request (and subsequent VM ops) then kill the program, then swap everything back in. It should clear after it gets done swapping. For a more effective memory test, try 'make -j8 world' a few times in parallel. Doug White Internet: dwhite@resnet.uoregon.edu | FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite | www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message