Date: Thu, 16 Aug 2012 11:40:17 -0500 From: Alan Cox <alc@rice.edu> To: "Jayachandran C." <c.jayachandran@gmail.com> Cc: mips@freebsd.org Subject: Re: mips pmap patch Message-ID: <502D2271.6080105@rice.edu> In-Reply-To: <CA%2B7sy7Cnsy7Ag1iG=_Kj04gEXeYp7kZnpACQpD8THvkp0VKdcA@mail.gmail.com> 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> <CA%2B7sy7Cnsy7Ag1iG=_Kj04gEXeYp7kZnpACQpD8THvkp0VKdcA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/15/2012 17:21, Jayachandran C. wrote:
> 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'd like to see the output of "sysctl vm.phys_segs" and "sysctl
vm.phys_free" from this machine. Even better would be running "sysctl
vm.phys_free" every 60 seconds during the buildworld. Finally, I'd like
to know whether or not either "ps" or "top" shows any threads blocked on
the "swwrt" wait channel once things slow to a crawl.
>> 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.
Thanks.
>> 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.
Ok. I don't think that the next change will require any specific tests.
Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?502D2271.6080105>