From owner-freebsd-hackers  Fri Aug 22 13:35:56 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id NAA00540
          for hackers-outgoing; Fri, 22 Aug 1997 13:35:56 -0700 (PDT)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA00528
          for <hackers@FreeBSD.ORG>; Fri, 22 Aug 1997 13:35:51 -0700 (PDT)
Received: (from root@localhost)
	by dyson.iquest.net (8.8.6/8.8.5) id PAA03372;
	Fri, 22 Aug 1997 15:35:38 -0500 (EST)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199708222035.PAA03372@dyson.iquest.net>
Subject: Re: Problems with > 256MB of RAM
In-Reply-To: <Pine.LNX.3.95.970822181529.7369B-100000@unicorn> from Gordon Henderson at "Aug 22, 97 06:33:33 pm"
To: gordon@drogon.net
Date: Fri, 22 Aug 1997 15:35:38 -0500 (EST)
Cc: hackers@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

I am not exactly familiar with DG's patch (probably have it filed
away somewhere.)  If you note the change in pmap.h, you'll see that a
parameter has been increased.  Just increase it again some more, perhaps
by double.  The pv_entry_t thing is problematical on large systems, and
the tuning method that I used in the 2.2 series was just wrong.  3.0 isn't
perfect right now, and am open for suggestions.  (DG changed it, and
made it much-much better in 3.0, but it still doesn't 'feel right' :-)).



> 
> 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
> 
> 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).
> 
> Whn it's running, a top output shows:
> 
>   PID USERNAME PRI NICE SIZE    RES STATE    TIME   WCPU    CPU COMMAND
>   189 root      2   0   236M 94376K select   0:00  0.00%  0.00% named
> 
> So it's only trying to grab an extra MB...
> 
> Any insight would be greatly appreciated.
> 
> Gordon
>