Date: Thu, 16 Aug 2012 03:51:34 +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%2B7sy7Cnsy7Ag1iG=_Kj04gEXeYp7kZnpACQpD8THvkp0VKdcA@mail.gmail.com> In-Reply-To: <5029635A.4050209@rice.edu> References: <50228F5C.1000408@rice.edu> <CA%2B7sy7DxqhGhJt%2BwE3WW2-j4SxnPweULjYS5GQ=NgMYSrwJHtw@mail.gmail.com> <50269AD4.9050804@rice.edu> <CA%2B7sy7AZ-s2H6COfvz60N=kxw%2BWUiUC9diVfWg9aOzWSZKGWRQ@mail.gmail.com> <5029635A.4050209@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 14, 2012 at 1:58 AM, Alan Cox <alc@rice.edu> wrote:
> On 08/13/2012 11:37, Jayachandran C. wrote:
>>
>> 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
>>>> particular, it reduces the size of a pv entry.
>>>>
>>>> Briefly, the big picture is that in order to move forward with further
>>>> locking 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
>>>> remove the page queues lock from the mips pmap, I need to port the new pv
>>>> entry 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
>>> testing.
>>>
>>> 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
>>> shrinks the size of a PV entry by almost half.
>>>
>>> 2. I observed and fixed a rather serious bug in pmap_remove_write().
>>> After removing write access from the physical page's first mapping,
>>> pmap_remove_write() then used the wrong "next" pointer. So, the page's
>>> second, third, etc. mapping would not be write protected. Instead, some
>>> arbitrary mapping 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.
>>
>
> What exactly happens? panic? deadlock?
The build slows down to a crawl and hangs when it runs out of pages in
the freelist.
> I'm attaching the next patch. This one replaces the page queues lock with a
> new lock that is private to the pmap.
Tested this with the same setup and I don't see any issues.
> After this patch gets committed, I will likely prepare a patch correcting
> the behavior of pmap_clear_modify(). It is not only clearing the modified
> bit/flag, but also doing two things that it shouldn't: calling
> vm_page_dirty() and I believe write protecting the page (which will trigger
> unnecessary soft faults).
Let me know if you need any specific tests to be done on these patches.
JC.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B7sy7Cnsy7Ag1iG=_Kj04gEXeYp7kZnpACQpD8THvkp0VKdcA>