kernel: Approaching the limit on PV entries...
tinguely at casselton.net
Sat Oct 11 02:47:00 UTC 2008
> > vm.pmap.pv_entry_count: 583006
> > vm.pmap.shpgperproc: 200
> > vm.pmap.pv_entry_max: 2243305
> > The system:
> > FreeBSD .... 7.0-RELEASE-p5 FreeBSD 7.0-RELEASE-p5 #0: Wed Oct 1
> > 07:51:58 UTC 2008
> > root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
> > Can someone briefly explain what this is telling me and how to decide
> > which sysctl to increase? I have found some old postings that predate
> > the sysctls that suggested increasing shpgperproc in the kernel
> > configuration, about 50 at a time until the problem goes away, but I
> > still have no clue what that is accomplishing.
the pv_entry helps the virtual memory system track physical pages, so a
physical page can be shared with another process or another virtual address.
In the i386/amd64 the pv_entry entries are allocated in page size "chunks"
on a per process memory map basis. This helps reduce redundant pointers
and overall saves memory.
"shpgperproc" can be read as "the number of shared pages per proceess".
pv_entry_max is calculated from shpgperproc (and on the amd64, shpgperproc
can be derived from setting the vm.pmap.pv_entry_max).
On the amd64, the values can be adjusted by sysctl, but on the i386
the values must be compiled into the kernel.
There are some automatic adjustments in the calculation of the number
of pv_entry, but the warnings are given early enough to help aid in the
tweaking of the value. The advice of slowly increasing vm.pmap.shpgperproc
is probably the best solution. I would adjust up slower than 50 (25%
increase seems to be pretty high).
More information about the freebsd-questions