From owner-freebsd-mips@FreeBSD.ORG Fri Jun 4 13:52:59 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A08CE1065674; Fri, 4 Jun 2010 13:52:59 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by mx1.freebsd.org (Postfix) with ESMTP id 6EE3B8FC0C; Fri, 4 Jun 2010 13:52:59 +0000 (UTC) Received: by pzk5 with SMTP id 5so657174pzk.14 for ; Fri, 04 Jun 2010 06:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LckJ0ey0Z9oRokbwknPd/6aka3iVkDBPlNba1j2HqLg=; b=pFibBQKg4MjiMqf/ccoFb0vXR5FiASf8q8k07fzjbnOIDTIHIwa9uS5yrX8dEdBUhA VrMLMKZsCXjxoSQTv98zkfyz+vwK3Jt3Wyn7/z21woinDjwybTvqIJ83/ETtZs3FJV8K M6Zd9Qw74KaFF7ailGTdYniDsHfVBj0s9wbD4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fU4fYbS7rGsEddnu79BMQwngabxeYq6aDw4WHULhbVL48oec9QI3fZnkNoa0IPbTZQ VEd2KjC0oj318IV7wAzDzaRvytY16YboXg0AZ3DpAJUq52oQTwxZ8yvupECtwKq0sMun 3mgQkK3HKRzxFVc12/S/WHGRN/TvHdj1cydWg= MIME-Version: 1.0 Received: by 10.141.187.12 with SMTP id o12mr8848257rvp.43.1275659578711; Fri, 04 Jun 2010 06:52:58 -0700 (PDT) Received: by 10.141.4.3 with HTTP; Fri, 4 Jun 2010 06:52:58 -0700 (PDT) In-Reply-To: <4C075196.4050101@cs.rice.edu> References: <4C0736A5.1010101@imimic.com> <4C075196.4050101@cs.rice.edu> Date: Fri, 4 Jun 2010 19:22:58 +0530 Message-ID: From: "C. Jayachandran" To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mips@freebsd.org Subject: Re: init_pte_prot() patch X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 13:52:59 -0000 On Thu, Jun 3, 2010 at 12:24 PM, Alan Cox wrote: > Juli Mallett wrote: >> >> Hi Alan, >> >> On Wed, Jun 2, 2010 at 21:59, Alan Cox 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.