mips pmap patch

[Jayachandran C.]

On Tue, Aug 14, 2012 at 1:58 AM, Alan Cox <alc at rice.edu> wrote:
> On 08/13/2012 11:37, Jayachandran C. wrote:
>>
>> On Sat, Aug 11, 2012 at 11:18 PM, Alan Cox<alc at rice.edu>  wrote:
>>>
>>> On 08/09/2012 10:36, Jayachandran C. wrote:
>>>
>>> On Wed, Aug 8, 2012 at 9:40 PM, Alan Cox<alc at 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.