init_pte_prot() patch

[Alan Cox]

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.

Alan

> Juli.
>