Date: Sat, 18 Aug 2012 17:22:24 -0400 From: Richard E Neese <r.neese@gmail.com> To: Alan Cox <alc@rice.edu> Cc: "arm@freebsd.org" <arm@freebsd.org> Subject: Re: arm pmap locking Message-ID: <50300790.5080104@gmail.com> In-Reply-To: <502FF174.8070102@rice.edu> References: <502FD67A.7030003@rice.edu> <1345315508.27688.260.camel@revolution.hippie.lan> <502FF174.8070102@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/18/2012 3:48 PM, Alan Cox wrote: > 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 > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" Alan what dream plug do you have what ver ? we are working on a patch now for dreamplug we have the dreamplug 1001 and 1001n and a 0801 so far
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50300790.5080104>