System panicked: pmap_get_physpage: out of memory

[Paul Ripke <stix%stix.id.au@localhost>]

New machine, amd64, netbsd-10 branch, 64G RAM. I have noticed that
under heavy file I/O, it manages to page - even though I have
vm.filemin=5, vm.filemax=10, and file RAM hit 86%, which I thought odd.
Last night it panicked running "find" as part of the daily scripts:

ksh$ crash -M netbsd.23.core -N netbsd.23
Crash version 10.1_STABLE, image version 10.1_STABLE.
crash: _kvm_kvatop(0)
Kernel compiled without options LOCKDEBUG.
System panicked: pmap_get_physpage: out of memory
Backtrace from time of crash is available.
crash> bt
sljit_modcmd() at 0
kern_reboot() at sys_reboot
vpanic() at vpanic+0x18d
panic() at vprintf
pmap_get_physpage() at pmap_growkernel
pmap_growkernel() at pmap_growkernel+0x167
uvm_map_prepare() at uvm_map_prepare+0x26d
uvm_map() at uvm_map+0x3c
uvm_km_alloc() at uvm_km_alloc+0x84
pool_grow() at pool_grow+0x78
pool_get() at pool_get+0x1d2
allocbuf() at allocbuf+0xb0
getblk() at getblk+0x138
bio_doread() at bio_doread+0x1c
bread() at bread+0x18
ffs_init_vnode() at ffs_init_vnode+0x9d
ffs_loadvnode() at ffs_loadvnode+0x43
vcache_get() at vcache_get+0x18a
ufs_lookup() at ufs_lookup+0xa6b
VOP_LOOKUP() at VOP_LOOKUP+0x3d
lookup_once() at lookup_once+0x193
namei_tryemulroot.constprop.0() at namei_tryemulroot.constprop.0+0x373
namei() at namei+0x43
do_sys_statat() at do_sys_statat+0x102
sys___lstat50() at sys___lstat50+0x25
syscall() at syscall+0x1fc
--- syscall (number 441) ---
syscall+0x1fc:

Pulling interesting bits out of uvmexp:

  npages = 16035645,
  free = 9923,
  paging = 0,
  wired = 4478,
  ncolors = 32,
  colormask = 31,
  zeropages = 0,
  reserve_pagedaemon = 1,
  reserve_kernel = 120,
  anonpages = 1097357,
  filepages = 12901680,
  execpages = 172070,
  freemin = 6144,
  freetarg = 8192,
  wiredmax = 5345215,
  nswapdev = 1,
  swpages = 16777215,
  swpgavail = 16777215,
  swpginuse = 775162,
  swpgonly = 526319,
...
  pdwoke = 419229,
  pdrevs = 111,
  pdfreed = 3339034,
  pdscans = 3591556,
  pdanscan = 827581,
  pdobscan = 2511535,
  pdreact = 237645,
  pdbusy = 0,
  pdpageouts = 52852,
  pdpending = 792146,
  pddeact = 8945762,
  pdreanon = 0,
  pdrefile = 0,
  pdreexec = 0,

So most of RAM was file pages, unsurprisingly, although free > freetarg.
This machine has 12 cores, 24 threads, so I'd imagine these stats might
be very racy with pdscan running elsewhere for a time during the crash?

For now, I'll try bumping freemin/freetarg, and see if that changes
anything. I think I have to concur with the comment in uvmpd_tune():

/*
 * try to keep 0.5% of available RAM free, but limit to between
 * 128k and 1024k per-CPU.  XXX: what are these values good for?
 */

Given core counts and speeds, these values might be a little stale?

-- 
Paul Ripke
"Great minds discuss ideas, average minds discuss events, small minds
 discuss people."
-- Disputed: Often attributed to Eleanor Roosevelt. 1948.