Date: Fri, 22 Aug 1997 15:35:38 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: gordon@drogon.net Cc: hackers@FreeBSD.ORG Subject: Re: Problems with > 256MB of RAM Message-ID: <199708222035.PAA03372@dyson.iquest.net> In-Reply-To: <Pine.LNX.3.95.970822181529.7369B-100000@unicorn> from Gordon Henderson at "Aug 22, 97 06:33:33 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708222035.PAA03372>