From owner-freebsd-mips@FreeBSD.ORG Thu Jun 3 06:01:56 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 1EADF1065686 for ; Thu, 3 Jun 2010 06:01:56 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id D9ECA8FC14 for ; Thu, 3 Jun 2010 06:01:55 +0000 (UTC) Received: by gwj23 with SMTP id 23so6202245gwj.13 for ; Wed, 02 Jun 2010 23:01:55 -0700 (PDT) Received: by 10.229.248.2 with SMTP id me2mr1750002qcb.44.1275543292315; Wed, 02 Jun 2010 22:34:52 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.220.199.70 with HTTP; Wed, 2 Jun 2010 22:34:32 -0700 (PDT) In-Reply-To: <4C0736A5.1010101@imimic.com> References: <4C0736A5.1010101@imimic.com> From: Juli Mallett Date: Wed, 2 Jun 2010 22:34:32 -0700 X-Google-Sender-Auth: DBc8WU9HF7XyX0Kyr9WMouuP-WQ Message-ID: To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alan Cox , 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: Thu, 03 Jun 2010 06:01:56 -0000 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 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 di= rty > 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 a= re > generally conditioned on the mapping having been for a managed page. > > The MIPS pmap_enter() is an exception to this rule. =A0It is unconditiona= lly > calling vm_page_dirty() on any page mapped within the kernel address spac= e, > managed or otherwise. =A0In fact, it is highly unusual for pmap_enter() t= o be > calling vm_page_dirty() on the page being mapped, regardless of whether i= t > is managed. =A0This call to vm_page_dirty() shouldn't be needed if change= #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. 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. 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. Juli.