Date: Mon, 03 Sep 2012 17:54:23 -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: <5045351F.6060201@rice.edu> In-Reply-To: <1346350374.1140.525.camel@revolution.hippie.lan> References: <502FD67A.7030003@rice.edu> <1345315508.27688.260.camel@revolution.hippie.lan> <503D12AE.1050705@rice.edu> <1346350374.1140.525.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5045351F.6060201>