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

M. Warner Losh imp at bsdimp.com
Mon Jul 26 14:29:31 UTC 2010


In message: <4C4D3AC1.8080201 at cs.rice.edu>
            Alan Cox <alc at cs.rice.edu> writes:
: 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.
: 
: For what it's worth, fixing pmap_change_wiring() and
: pmap_page_wired_mappings() is almost certainly more important.

what's broken with them now?

Warner


More information about the freebsd-mips mailing list