From owner-freebsd-arm@FreeBSD.ORG Mon Sep 3 22:54:32 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9121106564A for ; Mon, 3 Sep 2012 22:54:32 +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 90F578FC14 for ; Mon, 3 Sep 2012 22:54:32 +0000 (UTC) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id ECE09604EA; Mon, 3 Sep 2012 17:54:24 -0500 (CDT) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id EB280604C8; Mon, 3 Sep 2012 17:54:24 -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 EW83ZfWO3B3B; Mon, 3 Sep 2012 17:54:24 -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 74966603B0; Mon, 3 Sep 2012 17:54:24 -0500 (CDT) Message-ID: <5045351F.6060201@rice.edu> Date: Mon, 03 Sep 2012 17:54:23 -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: Ian Lepore References: <502FD67A.7030003@rice.edu> <1345315508.27688.260.camel@revolution.hippie.lan> <503D12AE.1050705@rice.edu> <1346350374.1140.525.camel@revolution.hippie.lan> In-Reply-To: <1346350374.1140.525.camel@revolution.hippie.lan> Content-Type: multipart/mixed; boundary="------------090307060108080103080901" Cc: "arm@freebsd.org" Subject: Re: arm pmap locking X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 22:54:33 -0000 This is a multi-part message in MIME format. --------------090307060108080103080901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/30/2012 13:12, Ian Lepore wrote: > On Tue, 2012-08-28 at 13:49 -0500, Alan Cox wrote: >> Can you please retry with the attached patch? For the time being, I >> decided to address the above problem by simply enabling recursion on the >> new pmap lock. As I mentioned in my prior message, the lock recursion >> in the arm pmap is a mistake. However, I'd rather not change two things >> at once, i.e., replace the page queues lock and fix the lock recursion. >> I'll take a look at eliminating the lock recursion later this week. >> >> Thanks, >> Alan >> > Sorry for the delay, I finally got around to trying this today, and it > seems to be working well initially -- it boots to multiuser and the only > difference in the dmesg.boot with and without the patch is the compile > date, and the kernel image is 128 bytes smaller with the patch. I've > got DIAGNOSTIC and INVARIANTS enabled; I'll run with the patch in place > and let you know if anything glitches. > Could you please test the attached patch? This is a small step toward disentangling the arm pmap locking. Alan --------------090307060108080103080901 Content-Type: text/plain; name="arm_pmap10.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arm_pmap10.patch" Index: arm/arm/pmap.c =================================================================== --- arm/arm/pmap.c (revision 240002) +++ arm/arm/pmap.c (working copy) @@ -1600,7 +1600,6 @@ static void pmap_enter_pv(struct vm_page *pg, struct pv_entry *pve, pmap_t pm, vm_offset_t va, u_int flags) { - int km; rw_assert(&pvh_global_lock, RA_WLOCKED); @@ -1617,10 +1616,8 @@ pmap_enter_pv(struct vm_page *pg, struct pv_entry TAILQ_INSERT_HEAD(&pg->md.pv_list, pve, pv_list); TAILQ_INSERT_HEAD(&pve->pv_pmap->pm_pvlist, pve, pv_plist); PMAP_UNLOCK(pmap_kernel()); - rw_wunlock(&pvh_global_lock); if ((pve = pmap_get_pv_entry()) == NULL) - panic("pmap_kenter_internal: no pv entries"); - rw_wlock(&pvh_global_lock); + panic("pmap_kenter_pv: no pv entries"); if (km) PMAP_LOCK(pmap_kernel()); } @@ -2835,11 +2832,8 @@ pmap_kenter_internal(vm_offset_t va, vm_offset_t p if (pvzone != NULL && (m = vm_phys_paddr_to_vm_page(pa))) { rw_wlock(&pvh_global_lock); if (!TAILQ_EMPTY(&m->md.pv_list) || m->md.pv_kva) { - /* release vm_page lock for pv_entry UMA */ - rw_wunlock(&pvh_global_lock); if ((pve = pmap_get_pv_entry()) == NULL) panic("pmap_kenter_internal: no pv entries"); - rw_wlock(&pvh_global_lock); PMAP_LOCK(pmap_kernel()); pmap_enter_pv(m, pve, pmap_kernel(), va, PVF_WRITE | PVF_UNMAN); --------------090307060108080103080901--