Date: Fri, 4 Jun 2010 19:22:58 +0530 From: "C. Jayachandran" <c.jayachandran@gmail.com> To: Alan Cox <alc@cs.rice.edu> Cc: mips@freebsd.org Subject: Re: init_pte_prot() patch Message-ID: <AANLkTimleT1PuG_pMF1sfk2Ild-omIW7iRcdv7wzVMkS@mail.gmail.com> In-Reply-To: <4C075196.4050101@cs.rice.edu> References: <4C0736A5.1010101@imimic.com> <AANLkTilICHWaFgEpjCV14wzFgtu_nSr8DGhWkXoO_Feq@mail.gmail.com> <4C075196.4050101@cs.rice.edu>
index | next in thread | previous in thread | raw e-mail
On Thu, Jun 3, 2010 at 12:24 PM, Alan Cox <alc@cs.rice.edu> wrote: > Juli Mallett wrote: >> >> Hi Alan, >> >> On Wed, Jun 2, 2010 at 21:59, Alan Cox <alc@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.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimleT1PuG_pMF1sfk2Ild-omIW7iRcdv7wzVMkS>