From owner-freebsd-hackers  Fri Aug 22 14:04:01 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA01915
          for hackers-outgoing; Fri, 22 Aug 1997 14:04:01 -0700 (PDT)
Received: from pat.idi.ntnu.no (0@pat.idi.ntnu.no [129.241.103.5])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA01894
          for <hackers@FreeBSD.ORG>; Fri, 22 Aug 1997 14:03:55 -0700 (PDT)
Received: from idt.unit.no (tegge@ikke.idi.ntnu.no [129.241.111.65])
	by pat.idi.ntnu.no (8.8.6/8.8.6) with ESMTP id XAA08591;
	Fri, 22 Aug 1997 23:03:43 +0200 (MET DST)
Message-Id: <199708222103.XAA08591@pat.idi.ntnu.no>
To: gordon@drogon.net
Cc: hackers@FreeBSD.ORG
Subject: Re: Problems with > 256MB of RAM
In-Reply-To: Your message of "Fri, 22 Aug 1997 18:33:33 +0100 (BST)"
References: <Pine.LNX.3.95.970822181529.7369B-100000@unicorn>
X-Mailer: Mew version 1.70 on Emacs 19.34.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Fri, 22 Aug 1997 23:03:42 +0200
From: Tor Egge <Tor.Egge@idi.ntnu.no>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> I'm running FreeBSD 2.2-STABLE on a machine with 384MB of RAM. (will be
> upgraded to 512MB soon). I'm having problems running named with very large
> zone files. The machine panics and reboots. A 'top' running on the machine
> at the time shows: 
> 
>   PID USERNAME PRI NICE SIZE    RES STATE    TIME   WCPU    CPU COMMAND
>  1418 root    105   0   235M   236M RUN      8:16 97.01% 97.01% named
> 
> It's always after it's allocated 235MB.
> 
> The panic message is always:
> 
>    panic: get_pv_entry: cannot get a pv_entry_t

There are two main reasons for this type of panic

	1. temporary shortage of free physical memory (cf PR#2431).

	   Use sysctl to increase limits of reserved free physical
	   memory, reducing the probability for running out of free memory.

	        sysctl -w vm.v_free_reserved=1024
	        sysctl -w vm.v_free_min=1500


	2. permanent shortage of virtual memory allocated for pv entries.

	   Increase the size of allocated virtual memory for pv entries
	   by adding:
		
		options         "PMAP_SHPGPERPROC=400"
	 
	   to the kernel config file. For most users, the default value
	   of 200 is big enough. I use 800. 

> The kernel has had 3 patches supplied by David Greenman <dg@root.com>,
> modifying files 
> 
>   /src/sys/i386/conf/Makefile.i386
>   /src/sys/i386/include/pmap.h
>   /src/sys/i386/include/vmparam.h
> 
> The only other bits that have been modified in the kernel config file
> (apart from deleting unused drivers, etc.) are:
> 
> maxusers        32
> options         "MAXMEM=393216"                 # 384MB
> options         "NMBCLUSTERS=2048"
> 
> options         "MAXDSIZ=402653184"             # 384MB
> options         "DFLDSIZ=402653184"             # 384MB
> 
> BOUNCE_BUFFERS are commented out.
> 
> Heres the catch: If I run a program that grabs all available memory in 1MB
> chunks (and writes to it as it grabs it), then exits (380MB later), then I
> can run named and it grows up to full size happily. (I'm running named
> 8.1.1, but I see the same with 4.9.6-REL).

This indicates that you probably have a temporary shortage of free physical
memory. This occur during fork() of big processes.

RES 236 MB -> 59000 pv entries needed -> 404 free physical pages needed.
	--> use a higher value, e.g. 1024 for vm.v_free_reserved

- Tor Egge