Subject: Re: Simple thought...
To: None <current-users@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: current-users
Date: 06/08/2002 02:05:51
[ On , June 7, 2002 at 13:00:45 (-0700), Wolfgang Rupprecht wrote: ]
> Subject: Re: Simple thought...
>
> 
> woods@weird.com (Greg A. Woods) writes:
> > I.e. if you have tons of RAM (more than necessary for the active page
> > sets of all your running processes) then make BUFCACHE (much) bigger:
> > 
> > 	options		BUFCACHE=25	# use up to 25% of RAM
> 
>  From memory:
> 
>     panic: cpu_startup: cannot allocate vm for buffers.
> 
> Normal startup looks like this:
> 
>     total memory = 767 MB
>     avail memory = 707 MB
>     using 6144 buffers containing 39400 KB of memory
> 
> Am I hitting some other table overflow by asking for 25% of memory to
> go to buffers?

Yes, the automatic allocation of NBUF is sub-optimal and you're probably
running out of kenel memory because of all the buffer headers.

Unfortunately options(4) doesn't discuss this.  Here's the text I wrote
some time ago when I figured this out for myself:

     options BUFCACHE=value
     Size of the buffer cache as a percentage of total available RAM.  Ignored
     if BUFPAGES is specified.

     options NBUF=value
     Sets the number of buffer headers available, i.e. the number of open
     files that may have a buffer cache entry.  Each buffer header requires
     MAXBSIZE (machine dependent, but usually 65536) bytes.  The default value
     is machine dependent, but is usually equal to the value of BUFPAGES.  If
     an architecture dependent VM_MAX_KERNEL_BUF constant is defined then NBUF
     may be reduced at run time so that the buffer headers don't exceed that
     limit.

     options BUFPAGES=value
     Sets the number of pages available for the buffer cache.  These pages are
     each CLBYTES in size (usually 4KB).  The default value is machine depen-
     dent, but is usually calculated as 10% of available RAM if there's only
     2MB or less available RAM, otherwise it's caclulated as 5% of the avail-
     able RAM.

(I thought I'd included those paragraphs in my PR#9068, but I see not....)

and I wrote this little patch to help me understand what was going on:

$ cvs diff kern_allocsys.c                                          
Index: kern_allocsys.c
===================================================================
RCS file: /cvs/NetBSD/src/sys/kern/kern_allocsys.c,v
retrieving revision 1.1.1.3
diff -c -r1.1.1.3 kern_allocsys.c
*** kern_allocsys.c     25 Mar 2001 08:05:58 -0000      1.1.1.3
--- kern_allocsys.c     21 Aug 2001 19:32:47 -0000
***************
*** 203,210 ****
         * XXX stopgap measure to prevent wasting too much KVM on
         * the sparsely filled buffer cache.
         */
!       if (nbuf * MAXBSIZE > VM_MAX_KERNEL_BUF)
                nbuf = VM_MAX_KERNEL_BUF / MAXBSIZE;
  #endif
  
        /*
--- 203,213 ----
         * XXX stopgap measure to prevent wasting too much KVM on
         * the sparsely filled buffer cache.
         */
!       if (nbuf * MAXBSIZE > VM_MAX_KERNEL_BUF) {
!               printf("nbuf at %d is too large for VM_MAX_KERNEL_BUF... ", nbuf);
                nbuf = VM_MAX_KERNEL_BUF / MAXBSIZE;
+               printf("adjusted to %d\n", nbuf);
+       }
  #endif
  
        /*

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>