From owner-freebsd-hackers Tue Mar 19 17:10:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 867EB37B400 for ; Tue, 19 Mar 2002 17:10:32 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 20 Mar 2002 01:10:31 +0000 (GMT) To: Kip Macy Cc: Miguel Mendez , hackers@FreeBSD.ORG Subject: Re: mmap and efence In-Reply-To: Your message of "Tue, 19 Mar 2002 13:11:35 PST." Date: Wed, 20 Mar 2002 01:10:29 +0000 From: Ian Dowse Message-ID: <200203200110.aa31284@salmon.maths.tcd.ie> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Kip Macy writes: >Looking at the source for efence this happens when mmap fails (in this case wi >th >ENOMEM). Looking at the man page the two possibilities are: the system has >reached the per-process mmap limit specified in the vm.max_proc_mmap sysctl or > >insufficient memory was available. *BSD limits the maximum amount of memory th >at >a process can mmap to swap+physical. I've also found it useful to increase the value of MEMORY_CREATION_SIZE in the ElectricFence source. Setting this to larger than the amount of address space ever used by the program seems to avoid the vm.max_proc_mmap limit; maybe when ElectricFence calls mprotect() to divide up its allocated address space, each part of the split region is counted as a separate mmap. I came across this before while debugging perl-Tk, and one other issue was that the program ran fantastically slowly; a trivial script that normally starts in a fraction of a second was taking close to an hour to get there on quite fast hardware. You expect ElectricFence to make things slow, but not quite that slow :-) Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message