Date: Sat, 18 Aug 2012 14:48:04 -0500 From: Alan Cox <alc@rice.edu> To: Ian Lepore <freebsd@damnhippie.dyndns.org> Cc: "arm@freebsd.org" <arm@freebsd.org> Subject: Re: arm pmap locking Message-ID: <502FF174.8070102@rice.edu> In-Reply-To: <1345315508.27688.260.camel@revolution.hippie.lan> References: <502FD67A.7030003@rice.edu> <1345315508.27688.260.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?502FF174.8070102>