From owner-freebsd-arm@FreeBSD.ORG Sat Aug 18 19:48:06 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 370A1106566C for ; Sat, 18 Aug 2012 19:48:06 +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 092C18FC12 for ; Sat, 18 Aug 2012 19:48:05 +0000 (UTC) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 4D576604ED; Sat, 18 Aug 2012 14:48:05 -0500 (CDT) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 4BFB1603D3; Sat, 18 Aug 2012 14:48:05 -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 7HqgJQ9Uw_Ip; Sat, 18 Aug 2012 14:48:05 -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 ED8D360392; Sat, 18 Aug 2012 14:48:04 -0500 (CDT) Message-ID: <502FF174.8070102@rice.edu> Date: Sat, 18 Aug 2012 14:48:04 -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> In-Reply-To: <1345315508.27688.260.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 18 Aug 2012 19:48:06 -0000 On 08/18/2012 13:45, Ian Lepore wrote: > On Sat, 2012-08-18 at 12:52 -0500, Alan Cox wrote: >> Can someone here please test the attached patch? I'm currently working >> my way through the various pmap implementations eliminating the use of >> the page queues lock. Arm is next on my list. >> >> Alan > I get a panic for recursion on my dreamplug, see attached. I applied > the patches over this: > > FreeBSD dpcur 10.0-CURRENT FreeBSD 10.0-CURRENT #4 r239193M: Sat Aug 18 > 12:37:24 MDT 2012 > > The 'M' is some dreamplug-specific changes (dts files, etc). I had a > quick look and it didn't seem like any of the checkins since r239193 > were related to arm pmap. I can try a fresher checkout when I have more > time if you think it's important. > > I tried adding WITNESS to see if it would get you more info, but it > panics for a LOR before getting to the panic in the attached output. > That's not new, it's been there for a while and I haven't had any time > to chase it down. Thanks, I don't need any more info. The problem is obvious. The existing arm pmap relies on the fact that lock recursion is allowed on the page queues lock that I'm eliminating, but not on the pvh lock that I'm introducing. However, this reliance on recursion is implicit not explicit. Look at the code surrounding the line were the lock acquire panics. It is explicitly releasing the page queues lock in the pre-patch version of the code, so as not to hold the page queues lock when pmap_get_pv_entry() is called. However, this unlocking and relocking is utterly pointless, because the caller to pmap_kenter_internal holds the page queues lock. So, in fact, pmap_get_pv_entry() will be called with the page queues lock held. Moreover, pmap_enter_locked() will call pmap_get_pv_entry() with the page queues lock held. So, I really don't understand why other places like pmap_kenter_internal() and pmap_enter_pv() are releasing and reacquiring the page queues lock. I suspect that it's based on the incorrect belief that you can't call uma_zalloc() with the page queues lock held. Let me look a little deeper at the arm pmap and I'll get back to you. Alan