svn commit: r210460 - head/sys/mips/include

[Jayachandran C.]

On Mon, Jul 26, 2010 at 1:05 PM, Alan Cox <alc at cs.rice.edu> wrote:
> M. Warner Losh wrote:
>>
>> In message: <AANLkTik+BV6u6fNVX8Ntb-G1yF=vEDh6VqB7Xcb5VtD- at mail.gmail.com>
>>            "Jayachandran C." <c.jayachandran at gmail.com> writes:
>> : On Sun, Jul 25, 2010 at 10:18 AM, Alan Cox <alc at cs.rice.edu> wrote:
>> : > Warner Losh wrote:
>> : >>
>> : >> Author: imp
>> : >> Date: Sun Jul 25 04:19:05 2010
>> : >> New Revision: 210460
>> : >> URL: http://svn.freebsd.org/changeset/base/210460
>> : >>
>> : >> Log:
>> : >>  Get N64 building by defining VM_FREELIST_DIRECT to be
>> : >>  VM_FREELIST_DEFAULT.  I believe this is correct, since KX is set in
>> : >>  n64, and thus all RAM can be direct mapped.
>> : : Thanks, this is something I missed in my MIPS page table changes.
>> : : >
>> : > Yes, it is.
>> : : In MIPS 64bit, whole physical memory is direct mapped thru a XKPHYS
>> : region. We can use vm_page_alloc() for pmap_alloc_pte_page() and
>> : VM_WAIT for pmap_grow_pte_page_cache(), is this something we should
>> : consider?
>>
>> Likely.  Any idea what kind of performance difference this would buy
>> us?
>>
>
> As long as n64 has a single free list, there is no point in changing
> pmap_alloc_pte_page() to use vm_page_alloc().  There may, however, be some
> point to using VM_WAIT in pmap_grow_pte_page_cache(), because
> vm_contig_grow_cache() is far more aggressive about paging out dirty pages
> than VM_WAIT is, and VM_WAIT would suffice.

Thanks - the 64 bit is the HEAD is still in early development, so I
was just trying to understand this better.

> For what it's worth, fixing pmap_change_wiring() and
> pmap_page_wired_mappings() is almost certainly more important.

I had seen the mail on this, but thought I will look at this after the
64 bit support work (if it is not fixed by then).

JC.