>Number:         6293
>Category:       kern
>Synopsis:       heavily-used server panics due to low MAX_KMAPENT
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Oct 14 15:35:01 1998
>Last-Modified:
>Originator:     John Darrow
>Organization:
	Computing Services
	Wheaton College, Wheaton, IL
>Release:        NetBSD-1.3.2, also NetBSD-current-19981012 on non-UVM archs
>Environment:
System: NetBSD scilab2.wheaton.edu 1.3.2 NetBSD 1.3.2 (SCI586) #0: Tue Aug 25 15:51:12 CDT 1998 jdarrow@scilab15.wheaton.edu:/var/src/sys/arch/i386/compile/SCI586 i386


>Description:
MAX_KMAPENT is set to 500 (1000 in -current) in sys/vm/vm_map.h,
with no ability to change it without directly editing vm_map.h .
This patch lets MAX_KMAPENT be changed by an 'options' line in
the config file, in the same manner as NKMEMCLUSTERS and NMBCLUSTERS.
(It also allows MAX_KMAP to be tweaked, though probably unnecessary.)

Here's Chuck Cranor's take on the problem, from tech-kern on 19981014:
- right (the 'XXXCDC' comment is mine, btw).   the VM system in 
- 1.3.2 allocates two or so kernel map entries per process due to 
- the unfortunate way it wires and unwires a process' u-area.  
- that's why doubling the MAX_KMAPENT value allows you to have 
- almost twice as many processes running at once.   as you've 
- discovered, when you run out of kernel map entries the system 
- panics.
-
- i changed the way the u-area is handled in UVM, so this shouldn't
- be a problem in -current (with UVM).   i eventually plan to modify
- UVM to dynamically allocate kernel map entries kind of like how
- freebsd and openbsd do it, but i haven't gotten to it yet.  once
- that is done, MAX_KMAPENT (and that panic) can be nuked.
-
- note that there is no need to adjust MAX_KMAP if your system boots
- properly.   kernel maps are only allocated at system startup time.
- i have already gotten rid of MAX_KMAP in UVM by changing the submap
- interface.
-
- chuck

>How-To-Repeat:
Notice 'vm_map_entry_create: out of map entries' panics while running
expire on news server.  Know you've got tweakable constants set high.
Go searching source for another constant to tweak.  Find it.  Notice it
can't be set from kernel config file.  Make local changes to allow setting
from config file.  See someone else post on tech-kern with same problem.
Decide to file a pr.

>Fix:

(Please pull up this change into 1.3.3, with or without upping the default)

Patch for 1.3.2 (vm_map,v 1.14):

*** vm_map.h_v1.14	Tue May  5 01:54:19 1998
--- vm_map.h	Thu Oct  1 10:11:02 1998
***************
*** 208,215 ****
--- 208,219 ----
  #define		vm_map_pmap(map)	((map)->pmap)
  
  /* XXX: number of kernel maps and entries to statically allocate */
+ #ifndef MAX_KMAP
  #define MAX_KMAP	10
+ #endif
+ #ifndef MAX_KMAPENT
  #define	MAX_KMAPENT	500
+ #endif
  
  #ifdef _KERNEL
  boolean_t	 vm_map_check_protection __P((vm_map_t,

Patch for current-19981012 (vm_map,v 1.20):

*** vm_map.h_v1.20	Mon Oct 12 06:11:04 1998
--- vm_map.h	Wed Oct 14 16:43:36 1998
***************
*** 256,265 ****
  #define		vm_map_pmap(map)	((map)->pmap)
  
  /* XXX: number of kernel maps and entries to statically allocate */
  #define MAX_KMAP	10
! #if 0
! #define	MAX_KMAPENT	500
! #else
  #define	MAX_KMAPENT	1000  /* XXXCDC: no crash */
  #endif
  
--- 256,265 ----
  #define		vm_map_pmap(map)	((map)->pmap)
  
  /* XXX: number of kernel maps and entries to statically allocate */
+ #ifndef MAX_KMAP
  #define MAX_KMAP	10
! #endif
! #ifndef MAX_KMAPENT
  #define	MAX_KMAPENT	1000  /* XXXCDC: no crash */
  #endif
  
>Audit-Trail:
>Unformatted: