Date: Mon, 13 Aug 2012 22:07:52 +0530 From: "Jayachandran C." <c.jayachandran@gmail.com> To: Alan Cox <alc@rice.edu> Cc: mips@freebsd.org Subject: Re: mips pmap patch Message-ID: <CA%2B7sy7AZ-s2H6COfvz60N=kxw%2BWUiUC9diVfWg9aOzWSZKGWRQ@mail.gmail.com> In-Reply-To: <50269AD4.9050804@rice.edu> References: <50228F5C.1000408@rice.edu> <CA%2B7sy7DxqhGhJt%2BwE3WW2-j4SxnPweULjYS5GQ=NgMYSrwJHtw@mail.gmail.com> <50269AD4.9050804@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Aug 11, 2012 at 11:18 PM, Alan Cox <alc@rice.edu> wrote:
>
> On 08/09/2012 10:36, Jayachandran C. wrote:
>
> On Wed, Aug 8, 2012 at 9:40 PM, Alan Cox <alc@rice.edu> wrote:
>>
>> Can someone please test this patch? It applies some changes to the mips=
pmap that were made a long time ago to the amd64 and i386 pmaps. In parti=
cular, it reduces the size of a pv entry.
>>
>> Briefly, the big picture is that in order to move forward with further l=
ocking refinements to the VM system's machine-independent layer, I need to =
eliminate all uses of the page queues lock from every pmap. In order to re=
move the page queues lock from the mips pmap, I need to port the new pv ent=
ry allocator from the amd64 and i386 pmaps. This patch is preparation for =
that.
>
>
> Tested the patch on XLP for about an hour ('make -j 64 buildworld' on 32 =
cpu mips64) and did not see any issues.
>
>
> Thank you for the quick response. I am attaching the next patch for test=
ing.
>
> This patch does two things:
>
> 1. It ports the new PV entry allocator from x86. This new allocator has =
two virtues. First, it doesn't use the page queues lock. Second, it shrin=
ks the size of a PV entry by almost half.
>
> 2. I observed and fixed a rather serious bug in pmap_remove_write(). Aft=
er removing write access from the physical page's first mapping, pmap_remov=
e_write() then used the wrong "next" pointer. So, the page's second, third=
, etc. mapping would not be write protected. Instead, some arbitrary mappi=
ng for a completely different page would be write protected, likely leading=
to spurious page faults later to reestablish write access to that mapping.
>
> This patch needs testing in both 32 bit and 64 bit kernels.
Ran the compile test on 32 and 64 bit kernels, and did not see any issue.
I could not test for more than an hour on 32-bit due to another
problem (freelist 1 containing direct-mapped pages runs out of pages
after about an hour of compile test). This issue has been there for a
long time, I am planning to look at it when I get a chance.
JC.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B7sy7AZ-s2H6COfvz60N=kxw%2BWUiUC9diVfWg9aOzWSZKGWRQ>