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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. =A0(A >>> "buildworld" would probably suffice.) =A0Essentially, it does two thing= s: >>> >> >> 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). =A0And, 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. =A0It is >>> unconditionally >>> calling vm_page_dirty() on any page mapped within the kernel address >>> space, >>> managed or otherwise. =A0In 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. =A0This call to vm_page_dirty() shouldn't be needed if chan= ge >>> #2 >>> below is also made. =A0The 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. > >> ... =A0This 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 di= rty > field, not the PTE_M bit in the PTE. =A0By removing the call to > vm_page_dirty(), I am not eliminating the optimization. =A0But, 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 bei= ng > mapped at a kernel virtual address. =A0There can exist unmanaged pages in= user > space on which this optimization could also be applied but is not today. = =A0My > patch fixes that. =A0If the page is unmanaged, whether it is in the kerne= l > address space or in a user address, PTE_M will be preset by my patch. > =A0Virtually all kernel pages are unmanaged. > > There do exist a very few managed pages in the kernel address space. =A0T= he > old code always preset PTE_M for these pages if the mapping was writeable= . > =A0With my patch, these mappings may not have PTE_M preset if the first a= ccess > is a read vm_fault() rather than a write vm_fault(). =A0If, however, the = first > access is a write vm_fault(), there will not be a subsequent emulation tr= ap. > >> ... =A0At >> least, that's what the intent appears to be. =A0Whether 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 virtu= al > 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. =A0The code is there, but likely not used recen= tly. I have tested a few SMP buildworld runs with this patch and it works so far= . JC.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimleT1PuG_pMF1sfk2Ild-omIW7iRcdv7wzVMkS>