init_pte_prot() patch

[C. Jayachandran]

On Thu, Jun 3, 2010 at 12:24 PM, Alan Cox <alc at cs.rice.edu> wrote:
> Juli Mallett wrote:
>>
>> 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.
>
> Yes, PTE_M and PTE_RW are aliases for the same 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.
>
> Just to be clear, vm_page_dirty() sets the machine-independent layer's dirty
> field, not the PTE_M bit in the PTE.  By removing the call to
> vm_page_dirty(), I am not eliminating the optimization.  But, I am
> eliminating a lot of needless calls to vm_page_dirty().
>
> As for the optimization of presetting PTE_M, I will argue that it should be
> based on whether or not the page is managed, not whether or not it is being
> mapped at a kernel virtual address.  There can exist unmanaged pages in user
> space on which this optimization could also be applied but is not today.  My
> patch fixes that.  If the page is unmanaged, whether it is in the kernel
> address space or in a user address, PTE_M will be preset by my patch.
>  Virtually all kernel pages are unmanaged.
>
> There do exist a very few managed pages in the kernel address space.  The
> old code always preset PTE_M for these pages if the mapping was writeable.
>  With my patch, these mappings may not have PTE_M preset if the first access
> is a read vm_fault() rather than a write vm_fault().  If, however, the first
> access is a write vm_fault(), there will not be a subsequent emulation trap.
>
>> ...  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.
>>
>
> Look at it this way: They were using the wrong information from the virtual
> memory system to implement their optimization.
>
> The one worry that I have about the patch is that the dirty bit emulation
> code may be rusty when it comes to handling dirty bit emulation traps for
> the kernel address space.  The code is there, but likely not used recently.

I have tested a few SMP buildworld runs with this patch and it works so far.

JC.