Date: Fri, 6 Aug 2010 15:59:09 +0530 From: "Jayachandran C." <c.jayachandran@gmail.com> To: Alan Cox <alc@cs.rice.edu> Cc: "Jayachandran C." <jchandra@freebsd.org>, mips@freebsd.org Subject: Re: svn commit: r210846 - in head/sys/mips: include mips Message-ID: <AANLkTinxAkRTK8pLRkQ7JwesNkuwmuiRevOZMDpj_aj7@mail.gmail.com> In-Reply-To: <4C5BA088.7060105@cs.rice.edu> References: <201008041412.o74ECAix092415@svn.freebsd.org> <4C5A569B.9090401@cs.rice.edu> <AANLkTinP7eMNm4yp6T2TTteSvthdgLJOj-ihHrQJ4T49@mail.gmail.com> <AANLkTi=vkG-cntJYYEdhO4AzOO91LB6n%2B45dUSxCMTp3@mail.gmail.com> <4C5BA088.7060105@cs.rice.edu>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Fri, Aug 6, 2010 at 11:11 AM, Alan Cox <alc@cs.rice.edu> wrote: > On 08/05/2010 09:25, Jayachandran C. wrote: >> >> On Thu, Aug 5, 2010 at 4:26 PM, Jayachandran C. >> <c.jayachandran@gmail.com> wrote: >> >>> >>> On Thu, Aug 5, 2010 at 11:43 AM, Alan Cox<alc@cs.rice.edu> wrote: >>> >>>> >>>> Just an observation ... >>>> >>>> Jayachandran C. wrote: >>>> >>>>> >>>>> Author: jchandra >>>>> Date: Wed Aug 4 14:12:09 2010 >>>>> New Revision: 210846 >>>>> URL: http://svn.freebsd.org/changeset/base/210846 >>>>> >>>>> Log: >>>>> Add 3 level page tables for MIPS in n64. >>>>> - 32 bit compilation will still use old 2 level page tables >>>>> - re-arrange pmap code so that adding another level is easier >>>>> - pmap code for 3 level page tables for n64 >>>>> - update TLB handler to traverse 3 levels in n64 >>>>> Reviewed by: jmallett >>>>> >>>> >>>> MIPS doesn't really need to use atomic_cmpset_int() in situations like >>>> this >>>> because the software dirty bit emulation in trap.c acquires the pmap >>>> lock. >>>> Atomics like this appear to be a carryover from i386 where the >>>> hardware-managed TLB might concurrently set the modified bit. >>>> >>> >>> Then I guess we should be able to use *pte directly, without pbits, >>> obits and the retry loop. >>> Will try this change... >>> >> >> Can you have a look at the attached patch and see if it is okay? This >> has the above changes, and I have attempted to fix the other issue you >> had reported on wired mapping count too. >> > > The patch looks good. > >> There are a few calls for loadandclear() on pte too, with pmap lock >> held, can this be avoided too? >> > > I haven't looked at them, but almost certainly yes. The calls are in pmap_remove_pte(), pmap_remove_all() and get_pv_entry(). the attached patch changes it normal pointer operations. Thought I would post it for review before checking in... Thanks, JC. [-- Attachment #2 --] Index: sys/mips/mips/pmap.c =================================================================== --- sys/mips/mips/pmap.c (revision 210922) +++ sys/mips/mips/pmap.c (working copy) @@ -1352,9 +1352,11 @@ pmap->pm_stats.resident_count--; pte = pmap_pte(pmap, va); KASSERT(pte != NULL, ("pte")); - oldpte = loadandclear((u_int *)pte); + oldpte = *pte; if (is_kernel_pmap(pmap)) *pte = PTE_G; + else + *pte = 0; KASSERT(!pte_test(&oldpte, PTE_W), ("wired pte for unwired page")); if (m->md.pv_flags & PV_TABLE_REF) @@ -1494,9 +1496,11 @@ mtx_assert(&vm_page_queue_mtx, MA_OWNED); PMAP_LOCK_ASSERT(pmap, MA_OWNED); - oldpte = loadandclear((u_int *)ptq); + oldpte = *ptq; if (is_kernel_pmap(pmap)) *ptq = PTE_G; + else + *ptq = 0; if (pte_test(&oldpte, PTE_W)) pmap->pm_stats.wired_count -= 1; @@ -1657,9 +1661,11 @@ pte = pmap_pte(pv->pv_pmap, pv->pv_va); - tpte = loadandclear((u_int *)pte); + tpte = *pte; if (is_kernel_pmap(pv->pv_pmap)) *pte = PTE_G; + else + *pte = 0; if (pte_test(&tpte, PTE_W)) pv->pv_pmap->pm_stats.wired_count--;home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinxAkRTK8pLRkQ7JwesNkuwmuiRevOZMDpj_aj7>