dump(8) and "Approaching the limit on PV entries"

I'm new to the present -CURRENT, so go easy on me.  :-)

I run periodic backups on my LAN at home, and since switching from
RELENG_6 I've begun to see this kernel message emit when dump(8)
runs with a dump level of 0 on one specific filesystem.  Incrementals,
at least so far, haven't caused this.

Sep 20 03:09:58 icarus kernel: Approaching the limit on PV entries, consider increasing tunables vm.pmap.shpgperproc or vm.pmap.pv_entry_max

The filesystem in question is a GEOM stripe class consisting of two disk
members, ad4 and ad6.  Sector sizes are default (512 bytes).  I chose a
stripe size of 256KB.

Filesystem      1024-blocks     Used     Avail Capacity  Mounted on
/dev/stripe/st0   946141880 80111848 790338688     9%    /storage

Additional tunefs parameters were used as well; everything is default
except:

tunefs: maximum blocks per file in a cylinder group: (-e)  16384
tunefs: average file size: (-f)                            65536
tunefs: average number of files in a directory: (-s)       256

How I'm doing backups:

  /sbin/dump -0 -a -h0 -u -C16 -L -f- /storage | dd of=/backups/storage.0.dump

I haven't tried removing the use of -C16 (16MB cache) to see if that
makes a difference.

I assumed vm.pmap.shpgperproc adjusted the number of shared VM pages
available per process, so I opted to increase that from 200 (default) to
1000 using loader.conf and reboot.  However, I still get the message,
which indicates I may need to apply further tuning.  But rather than
blindly increase numbers, I thought I'd ask others for recommendations
or clues as to what's going on.

Thanks for educating me.  :-)

-- 
| Jeremy Chadwick                                    jdc at parodius.com |
| Parodius Networking                           http://www.parodius.com/ |
| UNIX Systems Administrator                      Mountain View, CA, USA |
| Making life hard for others since 1977.                  PGP: 4BD6C0CB |