So I had a look at how and why pmap_kenter() is currently used.  For
the most part, it's used because it's supposed to be `faster'.  It
gets this `speed' by way of not dealing with R/M information at all.
But let's take a look at where it's actually used:

* Mapping file system buffers, the message buffer, and device
  registers.  These generally only happen at boot time (or module load
  time), and are thus not realistic performance issues.

* Mapping pages into the kernel for pagers and DMA.  Unfortunately, it
  seems to me to be canonically wrong to use pmap_kenter*() in these
  cases, precisely because it does throw away the M information.

* Mapping kmem pages.  This might be more realistic, except that some
  of these (particularly PCBs) actually do require M information
  because they're paged (unless you just always assume they're
  modified, which is sort of lame).  The only time it's safe to use it
  for kmem is, e.g., to allocate pool pages for objects that are never
  paged.  This isn't really a performance issue either.

So, I think pmap_kenter*() is pretty bogus, and should probably be
nuked.