From owner-freebsd-mips@FreeBSD.ORG Thu Aug 16 16:40:20 2012 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 5C62E106564A for ; Thu, 16 Aug 2012 16:40:20 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh10.mail.rice.edu (mh10.mail.rice.edu [128.42.201.30]) by mx1.freebsd.org (Postfix) with ESMTP id 215A58FC14 for ; Thu, 16 Aug 2012 16:40:19 +0000 (UTC) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 2FEB9604D7; Thu, 16 Aug 2012 11:40:19 -0500 (CDT) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 2E973604C6; Thu, 16 Aug 2012 11:40:19 -0500 (CDT) X-Virus-Scanned: by amavis-2.7.0 at mh10.mail.rice.edu, auth channel Received: from mh10.mail.rice.edu ([127.0.0.1]) by mh10.mail.rice.edu (mh10.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id ehfmjhkm6Ii9; Thu, 16 Aug 2012 11:40:19 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh10.mail.rice.edu (Postfix) with ESMTPSA id C6148604D5; Thu, 16 Aug 2012 11:40:18 -0500 (CDT) Message-ID: <502D2271.6080105@rice.edu> Date: Thu, 16 Aug 2012 11:40:17 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: "Jayachandran C." References: <50228F5C.1000408@rice.edu> <50269AD4.9050804@rice.edu> <5029635A.4050209@rice.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mips@freebsd.org Subject: Re: mips pmap 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, 16 Aug 2012 16:40:20 -0000 On 08/15/2012 17:21, Jayachandran C. wrote: > On Tue, Aug 14, 2012 at 1:58 AM, Alan Cox wrote: >> On 08/13/2012 11:37, Jayachandran C. wrote: >>> On Sat, Aug 11, 2012 at 11:18 PM, Alan Cox wrote: >>>> On 08/09/2012 10:36, Jayachandran C. wrote: >>>> >>>> On Wed, Aug 8, 2012 at 9:40 PM, Alan Cox wrote: >>>>> Can someone please test this patch? It applies some changes to the mips >>>>> pmap that were made a long time ago to the amd64 and i386 pmaps. In >>>>> particular, it reduces the size of a pv entry. >>>>> >>>>> Briefly, the big picture is that in order to move forward with further >>>>> locking refinements to the VM system's machine-independent layer, I need to >>>>> eliminate all uses of the page queues lock from every pmap. In order to >>>>> remove the page queues lock from the mips pmap, I need to port the new pv >>>>> entry allocator from the amd64 and i386 pmaps. This patch is preparation >>>>> for that. >>>> >>>> Tested the patch on XLP for about an hour ('make -j 64 buildworld' on 32 >>>> cpu mips64) and did not see any issues. >>>> >>>> >>>> Thank you for the quick response. I am attaching the next patch for >>>> testing. >>>> >>>> This patch does two things: >>>> >>>> 1. It ports the new PV entry allocator from x86. This new allocator has >>>> two virtues. First, it doesn't use the page queues lock. Second, it >>>> shrinks the size of a PV entry by almost half. >>>> >>>> 2. I observed and fixed a rather serious bug in pmap_remove_write(). >>>> After removing write access from the physical page's first mapping, >>>> pmap_remove_write() then used the wrong "next" pointer. So, the page's >>>> second, third, etc. mapping would not be write protected. Instead, some >>>> arbitrary mapping for a completely different page would be write protected, >>>> likely leading to spurious page faults later to reestablish write access to >>>> that mapping. >>>> >>>> This patch needs testing in both 32 bit and 64 bit kernels. >>> Ran the compile test on 32 and 64 bit kernels, and did not see any issue. >>> >>> I could not test for more than an hour on 32-bit due to another >>> problem (freelist 1 containing direct-mapped pages runs out of pages >>> after about an hour of compile test). This issue has been there for a >>> long time, I am planning to look at it when I get a chance. >>> >> What exactly happens? panic? deadlock? > The build slows down to a crawl and hangs when it runs out of pages in > the freelist. I'd like to see the output of "sysctl vm.phys_segs" and "sysctl vm.phys_free" from this machine. Even better would be running "sysctl vm.phys_free" every 60 seconds during the buildworld. Finally, I'd like to know whether or not either "ps" or "top" shows any threads blocked on the "swwrt" wait channel once things slow to a crawl. >> I'm attaching the next patch. This one replaces the page queues lock with a >> new lock that is private to the pmap. > Tested this with the same setup and I don't see any issues. Thanks. >> After this patch gets committed, I will likely prepare a patch correcting >> the behavior of pmap_clear_modify(). It is not only clearing the modified >> bit/flag, but also doing two things that it shouldn't: calling >> vm_page_dirty() and I believe write protecting the page (which will trigger >> unnecessary soft faults). > Let me know if you need any specific tests to be done on these patches. Ok. I don't think that the next change will require any specific tests. Alan