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.
