init_pte_prot() patch

[Alan Cox]

M. Warner Losh wrote:
> In message: <AANLkTilICHWaFgEpjCV14wzFgtu_nSr8DGhWkXoO_Feq at mail.gmail.com>
>             Juli Mallett <jmallett at FreeBSD.org> writes:
> : Hi Alan,
> : 
> : On Wed, Jun 2, 2010 at 21:59, Alan Cox <alc at imimic.com> wrote:
> : > I would appreciate it if someone would test the attached patch.  (A
> : > "buildworld" would probably suffice.)  Essentially, it does two things:
> : 
> : Sorry I didn't respond to this when you sent it to me.
> : 
> : > 1. The virtual memory system only cares about the contents of a page's dirty
> : > field if that page is managed (i.e., it is pageable).  And, in fact, if you
> : > survey the calls to vm_page_dirty() in the MIPS or any other pmap, they are
> : > generally conditioned on the mapping having been for a managed page.
> : >
> : > The MIPS pmap_enter() is an exception to this rule.  It is unconditionally
> : > calling vm_page_dirty() on any page mapped within the kernel address space,
> : > managed or otherwise.  In fact, it is highly unusual for pmap_enter() to be
> : > calling vm_page_dirty() on the page being mapped, regardless of whether it
> : > is managed.  This call to vm_page_dirty() shouldn't be needed if change #2
> : > below is also made.  The attached patch eliminates the call.
> : 
> : I believe that the reason the MIPS pmap does that is because
> : PTE_RWPAGE includes PTE_M which is the TLB dirty bit.  This means that
> : we won't get exceptions when that page is modified, and so MIPS is
> : pre-dirtying the VM page to allow it to make that optimization.  At
> : least, that's what the intent appears to be.  Whether that's a correct
> : model for the interaction between pmap and the VM system's management
> : of those kernel pages, I don't know.
>
> On MIPS, the hardware is such that the 'M' bit in the PTE needs to be
> set in order to write to the page.  So we need to set it on pages the
> kernel needs to write, otherwise we take a TLB exception on first
> write.  It is cheaper to pre-dirty kernel pages by setting the M bit
> in the TLB entry than to take the TLB miss and set it there.
>
> It isn't clear from me that this change takes that into account.  But
> it also is rare that things are clear to me in the vm layer without an
> hour of careful study :)
>   

It's handled by this case:

...
    } else
        /* Needn't emulate a modified bit for unmanaged pages. */
        rw = PTE_RWPAGE;

Alan